From dlong at openjdk.org  Thu Sep  1 02:20:08 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Sep 2022 02:20:08 GMT
Subject: RFR: 8292584: assert(cb != __null) failed: must be with
 -XX:-Inline [v5]
In-Reply-To: <ltsq2pVsQGv4-iOnjfH6CIlt5a--ZBZ8Gnb_hxaed0c=.078042e3-6d07-4576-87bf-e7726294fee4@github.com>
References: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
 <ltsq2pVsQGv4-iOnjfH6CIlt5a--ZBZ8Gnb_hxaed0c=.078042e3-6d07-4576-87bf-e7726294fee4@github.com>
Message-ID: <cdvoxCVIRFiE8jHik4yX1Dd3rJXVV1vb0mm1E-tIHKs=.7866a3d5-705e-4cc8-b51c-628b7efd6e11@github.com>

On Fri, 26 Aug 2022 07:01:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable.  The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame.  Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment.  The easiest fix is to undo what the c2i adapter might have done.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build failures

Thanks Ron.  Loom testing looks good so far.

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

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

From dlong at openjdk.org  Thu Sep  1 03:02:50 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Sep 2022 03:02:50 GMT
Subject: RFR: 8292584: assert(cb != __null) failed: must be with
 -XX:-Inline [v6]
In-Reply-To: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
References: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
Message-ID: <fTXgil2HOi4SFVndykfmeQVLK-BP_NesTWFBtNWOTzI=.96217b77-f8d6-458e-969e-480b0a95e238@github.com>

> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable.  The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame.  Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment.  The easiest fix is to undo what the c2i adapter might have done.

Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - merge fix
 - Merge master
 - fix build failures
 - fix zero build
 - cleanup
 - fix failed assert
 - version 2, make doYield a native intrinsic like enterSpecial
 - fix generate_Continuation_doYield_entry

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

Changes: https://git.openjdk.org/jdk/pull/9974/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9974&range=05
  Stats: 586 lines in 48 files changed: 194 ins; 340 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/9974.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9974/head:pull/9974

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

From iklam at openjdk.org  Thu Sep  1 03:36:17 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 1 Sep 2022 03:36:17 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v2]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <3fAN8xa-Y8qB5kL3lBgozmVwwIGIAYnR1ioShlDaufI=.9b7dbfcf-e07b-4e7b-95f2-90943aeef7ca@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed build (gcc spurious warning)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10110/files
  - new: https://git.openjdk.org/jdk/pull/10110/files/cd6ae283..c8882d1d

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

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

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

From ioi.lam at oracle.com  Thu Sep  1 04:47:46 2022
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 31 Aug 2022 21:47:46 -0700
Subject: RFC: Change CDS JAR file validation
Message-ID: <d4a49ea8-04c1-6e4d-8f2c-e5a85614b952@oracle.com>

Proposal Summary:

Use a digest of a JAR file to detect if the file has changed


Background
==========

CDS is in effect a caching mechanism -- it needs to make sure that the 
InstanceKlasses stored in the archive are the same as those parsed from 
classfiles.

To do this, we archive only the classes from (a) the JDK's modules image 
file and (b) JAR files. We don't archive classes in directories since 
it's difficult to check if the contents of a directory have changed.

At runtime, we assume that (a) didn't change, since we require the exact 
same JDK build to be used.

For (b) we currently do this:

(1) Check that -classpath and -Xbootclasspath (absolute paths) are 
identical between run time and dump time.
(2) For each JAR file in cp and bcp, check if its size and modification 
time has changed.
(3) (Something similar happens with the module path ....)

We have used this scheme for almost a decade. Note that we avoid reading 
the JAR files as that may slow down start-up time on old spinning disks. 
However, as most work-loads run on SSDs now, I believe this is no longer 
a concern.

Recently, we are seeing problems when people deploy CDS inside containers:

For (1) the file system structure may different between run time and 
dump time. We can kludge around this problem by using relative paths 
instead of absolute paths, but this will make the existing code even 
more complicated.

For (2) when deploying the app, it may not be easy to keep the 
modification time unchanged (see JDK-8284692).


Proposal
========

For (1) - don't not compare directory name anymore. Only check that the 
filename is the same:

E.g.

Dump:
 ??? java -Xshare:dump -cp dir1/Foo.jar:dir2/Bar.jar ..

Run:
 ??? java -cp dir1/Foo.jar:dir2/Bar.jar ... ??? [OK]
java -cp Foo.jar:Bar.jar ...??? ? ? ? ? ?? [OK]
 ??? java -cp Foo.jar:Bxx.jar ... [Fail - changed from Bar.jar to Bxx.jar]

For (2)

- Check that file size has not changed.
- Compute a digest of the file. Check that this has not changed.


Digest
======

The purpose is not for security or (malicious) tamper detection. It's 
for guarding against innocent mistakes (forgot to regenerate CDS archive 
after JAR files have been updated). Therefore, we don't need to run an 
expensive digest like MD5.

Instead, it should be enough to just do a quick XOR digest of the first 
128 bytes of the JAR file. Since this part usually contains the 
META-INF/ directory and its modification time. So it effectively 
contains the time when this JAR file was created. The timestamp seems to 
have a 2 second resolution:

$ while true; do jar cfm foo.jar MANIFEST.MF HelloWorld.class ; head -c 
128 foo.jar | cksum; sleep 2; done
3803507028 128
1857545662 128
916098721 128
3740087168 128
2260752543 128
3257546723 128
2584173820 128
...


Advantage:

- Make it easier to deploy CDS archive (fewer false negatives)
- Simplify logic in the CDS code

Risks:

- Opening every JAR file may cause a slow down if you have lots of JARs 
in the classpath running on a slow file system.


From darcy at openjdk.org  Thu Sep  1 05:23:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 05:23:25 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac [v2]
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <PhjxTbUT9SG0f9E9xTuaJtcO2dXs2BXBUiykCQN0VR8=.e1d79c6c-208e-4aa9-bd60-266e6d387842@github.com>

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

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

 - Update copyrights.
 - Delete unneeded test.
 - Merge branch 'master' into JDK-8173605
 - Merge branch 'master' into JDK-8173605
 - Small refactoring to remove more stale code.
 - Remove effectively dead code.
 - Adjust data for CheckExamples test.
 - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java.
 - Merge branch 'master' into JDK-8173605
 - Fix MultiReleaseJars.java.
 - ... and 17 more: https://git.openjdk.org/jdk/compare/a81a20ee...b2039d68

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10074/files
  - new: https://git.openjdk.org/jdk/pull/10074/files/f3095350..b2039d68

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

  Stats: 14641 lines in 536 files changed: 4475 ins; 7382 del; 2784 mod
  Patch: https://git.openjdk.org/jdk/pull/10074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074

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

From dholmes at openjdk.org  Thu Sep  1 06:46:19 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Sep 2022 06:46:19 GMT
Subject: RFR: 8291736: find_method_handle_intrinsic leaks Method* [v3]
In-Reply-To: <BylwK3lKu8czD81I87SagboToLTEwMzZS7Y7jBdGWRo=.9d15f4ae-4ff1-4710-95f5-23b71bd324c5@github.com>
References: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
 <W_G-7g0kAsZ3GhV8Tj73Jby0xDGayuAffLk_Xo3hCho=.d68d1bd0-f4af-41d5-9c1e-ac7e96e3cdfb@github.com>
 <nvTJ7hqqdlBAbNs8jo7SQXTi-XmEZuXhyiwTb1qgd00=.9d6f19e8-c9b7-45cc-a422-acb2f69cb9f0@github.com>
 <3_yOMnwYvjL4AjJFodW2TvWgW8sMbbAIRyq05o8queU=.600ead46-7ea0-454c-b3a3-3bc6925af79d@github.com>
 <f52ZOodQC96w15kqEIbuq9gzXdn3lGGde3VeUMlbWFg=.c19f03a1-cab6-45d6-81b5-93a01d17f194@github.com>
 <-Fw3NKgGxYOgZcX_w408mst9Ht1QyE6rr4bzXc7UD6Y=.7019579e-c511-4cfe-acaf-b27d8a040fd6@github.com>
 <BylwK3lKu8czD81I87SagboToLTEwMzZS7Y7jBdGWRo=.9d15f4ae-4ff1-4710-95f5-23b71bd324c5@github.com>
Message-ID: <gcgz_vbe4ZWjs05xy-uP7t4RGYQbc9S-iSx7gno8rn0=.0ec3f961-64b0-4db1-9e13-8caa0cf89359@github.com>

On Wed, 31 Aug 2022 13:24:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> This is a subtle interaction that only you noticed.
>> 
>> You mean in this review?  The original code clearly knew this had to be done outside the lock:
>> 
>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/e5b0439ef4ae#l33.106
>> 
>> Now perhaps the current code is actually safe (as @iklam suggests) because it can't actually invoke any Java code? But that is something we would need to establish. In any case it seems an anti-pattern to allow any kind of use of CHECK from inside a locked region when we "know" we always have to throw exceptions outside of locked regions.
>
> The problem with the original code was the ranking and multi-purpose use of the SystemDictionary_lock.  Creating the adapters takes out a lock whose ranking is above SystemDictionary_lock.  Also the tables (and lock for the tables) were shared with code that could call Java code for calling Java to create MethodType, so that code had to release the lock.  Leaking the java.lang.invoke.MethodType is ok because it'll be GC'd.
> 
> We've leaked the Method* and adapter for many years now, maybe it's fine to keep leaking it and I should just close this and not try to fix it.
> 
> The case of throwing exceptions inside Mutex locked regions is something I thought we have all over the source code.  I couldn't find any explicit calls, but the pattern of doing metaspace allocation inside of a MutexLocker is in enough places that adding an   assert(!thread->owns_locks(), "must release all locks when possibly throwing exceptions"); during in the TRAPS version of Metaspace::allocate() fails immediately.
> 
> But it may be that the OOM for Metaspace allocation failure doesn't call into Java for constructing the object and this part is fine.

Right, as per our side-bar discussion, while the general rule is "no throwing exceptions while holding a VM mutex/monitor" it seems that it is safe to only throw OutOfMemoryError because `Universe::gen_out_of_memory_error` doesn't execute any Java code. It either uses one of the pre-allocated OOME instances (if available) and fills in the stacktrace, or else (or in case of secondary OOM) it uses the pre-allocated stackless singleton instance.  This should be documented somewhere of course (and perhaps even programmatically verified somehow `NoJavaCodeVerifier`? :) )

Also whilst the lower-level code makes it somewhat clear that the only exception that can arise is the metaspace OOME, it is not at all clear just by looking at a callsite like:

methodHandle m = Method::make_method_handle_intrinsic(iid, signature, CHECK_NULL);

so perhaps we even need additional macros like CHECK_OOM to verify only OOME can be thrown? (Not in this PR.)

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

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

From dholmes at openjdk.org  Thu Sep  1 06:56:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Sep 2022 06:56:05 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging
In-Reply-To: <XGF64pPwz8kncJEngAEifQ4wQYGYZJ4ojUep2puvc4c=.b8e607cc-50ac-4be1-9af4-99a5fada36eb@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
 <u03k2oYlsZrveJXrHXSejGeBPsn3mYX6PTGu3ZaRhA0=.c4b6a960-0b87-4b00-8ed1-47f0ac9950f0@github.com>
 <XGF64pPwz8kncJEngAEifQ4wQYGYZJ4ojUep2puvc4c=.b8e607cc-50ac-4be1-9af4-99a5fada36eb@github.com>
Message-ID: <J-31C46f605wRLxrZ1In5bJaZ4Z6Uv1GFeTW4vUE-Tk=.4e997eaf-d72d-425e-8ce8-107f78cc8f40@github.com>

On Fri, 26 Aug 2022 13:44:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/loaderConstraints.cpp line 201:
>> 
>>> 199:         if (lt.is_enabled()) {
>>> 200:           ResourceMark rm;
>>> 201:           lt.print("purging class object from constraint for name %s,"
>> 
>> You are doing more than just purging the class object now.
>
> Right.  This purges the entire constraint for the unloaded class object, without looping through the loader entries and doing it separately.  They should always be purged.

My point being the log message is no longer accurate.

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

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

From shade at openjdk.org  Thu Sep  1 08:40:45 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 08:40:45 GMT
Subject: RFR: 8293201: Library detection in
 runtime/ErrorHandling/TestDwarf.java fails on some systems
Message-ID: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>

When building x86_32 on Ubuntu 22.04, the test fails to find the library name in `"C  [libc.so.6+0x85ff1]"`, because the regexp seems too broad. Since we are matching with the unanchored regexp, we can just try and find the smaller prefix, which still matches the library name.

But the original regexp seems odd to begin with. Why do we match `0x` twice? Why do we have the escaped `\[`, followed by trailing `]` (the last one in the patch now), which is not escaped? This is a question for you, @chhagedorn :)

Additional testing:
 - [x] Ubuntu 22.04 x86_32 build

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

Commit messages:
 - Fix

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

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

From chagedorn at openjdk.org  Thu Sep  1 09:39:08 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 1 Sep 2022 09:39:08 GMT
Subject: RFR: 8293201: Library detection in
 runtime/ErrorHandling/TestDwarf.java fails on some systems
In-Reply-To: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
References: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
Message-ID: <ywZ-0jm2fETthb5KJmDeFb7VndE5oMnAU6Goy7WrS6A=.ec6a525a-6e03-4f3f-a46f-f961dc835ad4@github.com>

On Thu, 1 Sep 2022 08:32:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When building x86_32 on Ubuntu 22.04, the test fails to find the library name in `"C  [libc.so.6+0x85ff1]"`, because the regexp seems too broad. Since we are matching with the unanchored regexp, we can just try and find the smaller prefix, which still matches the library name.
> 
> But the original regexp seems odd to begin with. Why do we match `0x` twice? Why do we have the escaped `\[`, followed by trailing `]` (the last one in the patch now), which is not escaped? This is a question for you, @chhagedorn :)
> 
> Additional testing:
>  - [x] Ubuntu 22.04 x86_32 build

Looks good and trivial! Thanks for fixing that.

> But the original regexp seems odd to begin with. Why do we match 0x twice? 

I've tried to match as much as possible of the output that seemed to be always there to be sure not to match any other lines. But looking at that regex again, it seems I went a little bit over the top. Anyhow, I've (wrongly) assumed that we will always find the offset (second `0x`) of a method in a line:

```V  [libjvm.so+0x6ab1d0]  Compilation::~Compilation()+0x56  (c1_Compilation.cpp:616)```

But it looks like that's wrong and we could only have `"C [libc.so.6+0x85ff1]"`. Matching only on that is indeed enough for that check.

> Why do we have the escaped \[, followed by trailing ] (the last one in the patch now), which is not escaped?

My IDE suggested that I can get rid of the second escape of the closing `]` at the end of the regex (I did not know that I can do that before). It seems to treat it as normal character when there is no (non-escaping) opening `[` before that.

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

Marked as reviewed by chagedorn (Reviewer).

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

From shade at openjdk.org  Thu Sep  1 11:47:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 11:47:14 GMT
Subject: RFR: 8293201: Library detection in
 runtime/ErrorHandling/TestDwarf.java fails on some systems
In-Reply-To: <ywZ-0jm2fETthb5KJmDeFb7VndE5oMnAU6Goy7WrS6A=.ec6a525a-6e03-4f3f-a46f-f961dc835ad4@github.com>
References: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
 <ywZ-0jm2fETthb5KJmDeFb7VndE5oMnAU6Goy7WrS6A=.ec6a525a-6e03-4f3f-a46f-f961dc835ad4@github.com>
Message-ID: <KNlZ5ksFKV6HYx9kbW4ItNogPn0ZOck5iSujYKdu_g8=.086c82bc-dafe-4db5-b969-b0a029712f46@github.com>

On Thu, 1 Sep 2022 09:37:01 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Looks good and trivial! Thanks for fixing that.
> 
> > But the original regexp seems odd to begin with. Why do we match 0x twice?
> 
> I've tried to match as much as possible of the output that seemed to be always there to be sure not to match any other lines. But looking at that regex again, it seems I went a little bit over the top. Anyhow, I've (wrongly) assumed that we will always find the offset (second `0x`) of a method in a line:
> 
> `V [libjvm.so+0x6ab1d0] Compilation::~Compilation()+0x56 (c1_Compilation.cpp:616)`

I see! Yeah, that's unnecessary on the paths that check the missing libraries/symbols.

> > Why do we have the escaped [, followed by trailing ] (the last one in the patch now), which is not escaped?
> 
> My IDE suggested that I can get rid of the second escape of the closing `]` at the end of the regex (I did not know that I can do that before). It seems to treat it as normal character when there is no (non-escaping) opening `[` before that.

Oh. My in-brain regex parser threw parse errors at this. Seems like an odd thing to allow, ha!

I am sure this fix works in my Ubuntu 22.04 VM, but I am checking that it also fixes GHA: https://github.com/shipilev/jdk/runs/8134142556 -- if so, I'll integrate under trivial rule.

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

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

From chagedorn at openjdk.org  Thu Sep  1 11:54:05 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 1 Sep 2022 11:54:05 GMT
Subject: RFR: 8293201: Library detection in
 runtime/ErrorHandling/TestDwarf.java fails on some systems
In-Reply-To: <KNlZ5ksFKV6HYx9kbW4ItNogPn0ZOck5iSujYKdu_g8=.086c82bc-dafe-4db5-b969-b0a029712f46@github.com>
References: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
 <ywZ-0jm2fETthb5KJmDeFb7VndE5oMnAU6Goy7WrS6A=.ec6a525a-6e03-4f3f-a46f-f961dc835ad4@github.com>
 <KNlZ5ksFKV6HYx9kbW4ItNogPn0ZOck5iSujYKdu_g8=.086c82bc-dafe-4db5-b969-b0a029712f46@github.com>
Message-ID: <D73ICt9OQYfiUS90YFPkHg30PVJI9LcH4g8cSyp6IYw=.4821adff-71a8-4bb0-9928-5eececd17e2b@github.com>

On Thu, 1 Sep 2022 11:45:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Looks good and trivial! Thanks for fixing that.
> > > But the original regexp seems odd to begin with. Why do we match 0x twice?
> > 
> > 
> > I've tried to match as much as possible of the output that seemed to be always there to be sure not to match any other lines. But looking at that regex again, it seems I went a little bit over the top. Anyhow, I've (wrongly) assumed that we will always find the offset (second `0x`) of a method in a line:
> > `V [libjvm.so+0x6ab1d0] Compilation::~Compilation()+0x56 (c1_Compilation.cpp:616)`
> 
> I see! Yeah, that's unnecessary on the paths that check the missing libraries/symbols.

Indeed!

> 
> > > Why do we have the escaped [, followed by trailing ] (the last one in the patch now), which is not escaped?
> > 
> > 
> > My IDE suggested that I can get rid of the second escape of the closing `]` at the end of the regex (I did not know that I can do that before). It seems to treat it as normal character when there is no (non-escaping) opening `[` before that.
> 
> Oh. My in-brain regex parser threw parse errors at this. Seems like an odd thing to allow, ha!

Right, I also think that's odd :-)

> 
> I am sure this fix works in my Ubuntu 22.04 VM, but I am checking that it also fixes GHA: https://github.com/shipilev/jdk/runs/8134142556 -- if so, I'll integrate under trivial rule.

Sounds good.

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

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

From coleenp at openjdk.org  Thu Sep  1 12:39:38 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 12:39:38 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging
In-Reply-To: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
Message-ID: <4jLdo5Xha3pwklvzilDVDSYyXc-IwYruoSt462KIzjg=.96f9f9fb-ddec-4f9d-85bf-b224d008af05@github.com>

On Thu, 25 Aug 2022 12:56:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
> 
> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
> 
> Tested with tier1-3 which contains jck tests.

Ok, I unrenamed probe to constraint.  Hope this helps.

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

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

From coleenp at openjdk.org  Thu Sep  1 12:39:37 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 12:39:37 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v2]
In-Reply-To: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
Message-ID: <bCevreBwPGSRX4hf4OzKqZPI1iWIjFMG53WvCYCDwDo=.ecb5ee7c-6c74-4764-a84a-51a8e05fbdbd@github.com>

> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
> 
> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
> 
> Tested with tier1-3 which contains jck tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Unrename probe to constraint

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10023/files
  - new: https://git.openjdk.org/jdk/pull/10023/files/dae25c41..d9726237

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

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

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

From coleenp at openjdk.org  Thu Sep  1 12:44:39 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 12:44:39 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v3]
In-Reply-To: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
Message-ID: <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>

> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
> 
> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
> 
> Tested with tier1-3 which contains jck tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Copy logging rather than passing name to remove_constraint.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10023/files
  - new: https://git.openjdk.org/jdk/pull/10023/files/d9726237..2e5561f9

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

  Stats: 22 lines in 1 file changed: 12 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10023.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10023/head:pull/10023

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

From shade at openjdk.org  Thu Sep  1 14:18:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 14:18:17 GMT
Subject: RFR: 8293201: Library detection in
 runtime/ErrorHandling/TestDwarf.java fails on some systems
In-Reply-To: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
References: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
Message-ID: <YCTYu6YXS7X9lRsg33f_FhN6fco1hJgONwRyak6U-go=.f4192609-4aab-4eca-a314-28859ae4fc23@github.com>

On Thu, 1 Sep 2022 08:32:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When building x86_32 on Ubuntu 22.04, the test fails to find the library name in `"C  [libc.so.6+0x85ff1]"`, because the regexp seems too broad. Since we are matching with the unanchored regexp, we can just try and find the smaller prefix, which still matches the library name.
> 
> But the original regexp seems odd to begin with. Why do we match `0x` twice? Why do we have the escaped `\[`, followed by trailing `]` (the last one in the patch now), which is not escaped? This is a question for you, @chhagedorn :)
> 
> Additional testing:
>  - [x] Ubuntu 22.04 x86_32 build

GHA is good, I am integrating.

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

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

From shade at openjdk.org  Thu Sep  1 14:18:18 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 14:18:18 GMT
Subject: Integrated: 8293201: Library detection in
 runtime/ErrorHandling/TestDwarf.java fails on some systems
In-Reply-To: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
References: <AAaoKKCcde10KY_GQOTghSCvE5w3dDE-VFp9oYePmqw=.96c7487b-d1a4-4020-8564-aeddc072e263@github.com>
Message-ID: <rHNexyG2ciZ-vXnVF3gx_Fl2gRYdZhvutrSffBphZeA=.902dfb38-18a2-49de-a5de-aa3d6dd5953d@github.com>

On Thu, 1 Sep 2022 08:32:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When building x86_32 on Ubuntu 22.04, the test fails to find the library name in `"C  [libc.so.6+0x85ff1]"`, because the regexp seems too broad. Since we are matching with the unanchored regexp, we can just try and find the smaller prefix, which still matches the library name.
> 
> But the original regexp seems odd to begin with. Why do we match `0x` twice? Why do we have the escaped `\[`, followed by trailing `]` (the last one in the patch now), which is not escaped? This is a question for you, @chhagedorn :)
> 
> Additional testing:
>  - [x] Ubuntu 22.04 x86_32 build

This pull request has now been integrated.

Changeset: 52045282
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5204528296a53d7dc77e67b26be23a64692527fa
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8293201: Library detection in runtime/ErrorHandling/TestDwarf.java fails on some systems

Reviewed-by: chagedorn

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

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

From coleenp at openjdk.org  Thu Sep  1 15:01:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 15:01:26 GMT
Subject: RFR: 8291736: find_method_handle_intrinsic leaks Method* [v4]
In-Reply-To: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
References: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
Message-ID: <nJOCIGdD6TSz_RSgWXpupKT8D3U2KoZpNdl9hiDK4FA=.cadf61d6-8c7a-477a-b642-2cd1242856ac@github.com>

> As part of the SymbolPropertyTable conversion, we noticed that threads could race to add the Method entry to the table, and the loser wasn't deleted.  This change locks the InvokeMethodTable_lock through the Method creation so that it's not leaked.  See bug for details, but this was performance tested with our general suite of performance tests to show no significant differences.
> Also tested with tier1-3, and previously 4-7 with SymbolPropertyTable conversion patch.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9983/files
  - new: https://git.openjdk.org/jdk/pull/9983/files/f8e85da2..d0ead64c

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

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

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

From darcy at openjdk.org  Thu Sep  1 16:46:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 16:46:21 GMT
Subject: Integrated: JDK-8173605: Remove support for source and target 1.7
 option in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <gbPQrgcQ4ahoMdC7kieutONxygrBOxirKmi5HmDu-10=.d68cd13f-d992-443b-9353-2a19ef40cd8d@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

This pull request has now been integrated.

Changeset: 2d18dda3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d18dda3f2074a4f8b9a0c62ece9ac6d5284e93b
Stats:     4595 lines in 156 files changed: 25 ins; 4413 del; 157 mod

8173605: Remove support for source and target 1.7 option in javac

Reviewed-by: vromero

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

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

From iklam at openjdk.org  Thu Sep  1 17:51:07 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 1 Sep 2022 17:51:07 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v3]
In-Reply-To: <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
 <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
Message-ID: <AP3voB9JQ1Q-70sKVxvXWhVA3eVsNNp99rryDh4r6LM=.24e19d7c-8f83-4ba1-b046-b4b6562e4d6d@github.com>

On Thu, 1 Sep 2022 12:44:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
>> 
>> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
>> 
>> Tested with tier1-3 which contains jck tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copy logging rather than passing name to remove_constraint.

Changes requested by iklam (Reviewer).

src/hotspot/share/classfile/loaderConstraints.cpp line 193:

> 191:       if (klass != NULL &&
> 192:           !klass->is_loader_alive()) {
> 193:         probe->set_klass(NULL);

When was this `probe` removed in the old code? I could only see this in the old code,


        if (probe->num_loaders() < 2) {
          set.remove_constraint(probe);
        }


I am wondering if the old code actually had a memory leak in this case.

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

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

From coleenp at openjdk.org  Thu Sep  1 18:13:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 18:13:25 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v3]
In-Reply-To: <AP3voB9JQ1Q-70sKVxvXWhVA3eVsNNp99rryDh4r6LM=.24e19d7c-8f83-4ba1-b046-b4b6562e4d6d@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
 <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
 <AP3voB9JQ1Q-70sKVxvXWhVA3eVsNNp99rryDh4r6LM=.24e19d7c-8f83-4ba1-b046-b4b6562e4d6d@github.com>
Message-ID: <Bk-2CTT1ft2XzrlD7JCUUX-Hj26yRbV0X8R1NxrN4sM=.0ab4a335-c7a2-48ea-8d75-b75df99fdd8b@github.com>

On Thu, 1 Sep 2022 17:41:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copy logging rather than passing name to remove_constraint.
>
> src/hotspot/share/classfile/loaderConstraints.cpp line 193:
> 
>> 191:       if (klass != NULL &&
>> 192:           !klass->is_loader_alive()) {
>> 193:         probe->set_klass(NULL);
> 
> When was this `probe` removed in the old code? I could only see this in the old code,
> 
> 
>         if (probe->num_loaders() < 2) {
>           set.remove_constraint(probe);
>         }
> 
> 
> I am wondering if the old code actually had a memory leak in this case.

That's when the probe was removed in the old code, the code was reached unconditionally whether klass is alive or not.  If it wasn't removed, we do assert that klass is alive.  I was trying to figure out why 2, but if the constraint wasn't between at least two loaders (if the rest of the loaders are unloaded, you might still have bootstrap remaining, which is never removed), it should be removed.

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

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

From iklam at openjdk.org  Thu Sep  1 18:25:25 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 1 Sep 2022 18:25:25 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v3]
In-Reply-To: <Bk-2CTT1ft2XzrlD7JCUUX-Hj26yRbV0X8R1NxrN4sM=.0ab4a335-c7a2-48ea-8d75-b75df99fdd8b@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
 <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
 <AP3voB9JQ1Q-70sKVxvXWhVA3eVsNNp99rryDh4r6LM=.24e19d7c-8f83-4ba1-b046-b4b6562e4d6d@github.com>
 <Bk-2CTT1ft2XzrlD7JCUUX-Hj26yRbV0X8R1NxrN4sM=.0ab4a335-c7a2-48ea-8d75-b75df99fdd8b@github.com>
Message-ID: <MErms6-Ok2a4we52yaqpNlTBKrWooUZbBjfYDS3X34k=.a482a1b6-619c-4404-a2fb-a61c115ed7b8@github.com>

On Thu, 1 Sep 2022 18:08:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/loaderConstraints.cpp line 193:
>> 
>>> 191:       if (klass != NULL &&
>>> 192:           !klass->is_loader_alive()) {
>>> 193:         probe->set_klass(NULL);
>> 
>> When was this `probe` removed in the old code? I could only see this in the old code,
>> 
>> 
>>         if (probe->num_loaders() < 2) {
>>           set.remove_constraint(probe);
>>         }
>> 
>> 
>> I am wondering if the old code actually had a memory leak in this case.
>
> That's when the probe was removed in the old code, the code was reached unconditionally whether klass is alive or not.  If it wasn't removed, we do assert that klass is alive.  I was trying to figure out why 2, but if the constraint wasn't between at least two loaders (if the rest of the loaders are unloaded, you might still have bootstrap remaining, which is never removed), it should be removed.

How about adding a test to check for "purging complete constraint for name" in the log to make sure this code is exercised?

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

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

From iklam at openjdk.org  Thu Sep  1 18:25:25 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 1 Sep 2022 18:25:25 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v3]
In-Reply-To: <MErms6-Ok2a4we52yaqpNlTBKrWooUZbBjfYDS3X34k=.a482a1b6-619c-4404-a2fb-a61c115ed7b8@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
 <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
 <AP3voB9JQ1Q-70sKVxvXWhVA3eVsNNp99rryDh4r6LM=.24e19d7c-8f83-4ba1-b046-b4b6562e4d6d@github.com>
 <Bk-2CTT1ft2XzrlD7JCUUX-Hj26yRbV0X8R1NxrN4sM=.0ab4a335-c7a2-48ea-8d75-b75df99fdd8b@github.com>
 <MErms6-Ok2a4we52yaqpNlTBKrWooUZbBjfYDS3X34k=.a482a1b6-619c-4404-a2fb-a61c115ed7b8@github.com>
Message-ID: <eG4UH9EcdSA3cD91fSUP5Fftmq3qezo1ds-kftlfeVk=.e2f44d03-4f60-411b-9d4a-507d87ce63ec@github.com>

On Thu, 1 Sep 2022 18:20:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> That's when the probe was removed in the old code, the code was reached unconditionally whether klass is alive or not.  If it wasn't removed, we do assert that klass is alive.  I was trying to figure out why 2, but if the constraint wasn't between at least two loaders (if the rest of the loaders are unloaded, you might still have bootstrap remaining, which is never removed), it should be removed.
>
> How about adding a test to check for "purging complete constraint for name" in the log to make sure this code is exercised?

And why was this assert removed?


          assert(probe->klass()->is_loader_alive(), "klass should be live");

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

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

From ccheung at openjdk.org  Thu Sep  1 19:05:10 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 1 Sep 2022 19:05:10 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v2]
In-Reply-To: <3fAN8xa-Y8qB5kL3lBgozmVwwIGIAYnR1ioShlDaufI=.9b7dbfcf-e07b-4e7b-95f2-90943aeef7ca@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3fAN8xa-Y8qB5kL3lBgozmVwwIGIAYnR1ioShlDaufI=.9b7dbfcf-e07b-4e7b-95f2-90943aeef7ca@github.com>
Message-ID: <tB9NajK7xzlxjzxMnkf6_StQy1wFeyXyby2ijmfcpyw=.73136649-1f52-40d8-bc2e-3cac41093f78@github.com>

On Thu, 1 Sep 2022 03:36:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
>> 
>> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
>> 
>> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
>> 
>> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
>> 
>> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
>> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed build (gcc spurious warning)

Some initial comments...

src/hotspot/share/cds/cds_globals.hpp line 78:

> 76:           "product builds. If specified, the static field named "           \
> 77:           "\"archivedObjects\" in this class is stored into the CDS "       \
> 78:           "archive heap")                                                   \

The ?this class? wasn?t clear to me until I read the test case. I?d suggest something like the following:


?The ""archivedObjects" static field of the specified?
?class is stored in the CDS archive heap."

src/hotspot/share/cds/heapShared.cpp line 1619:

> 1617:   int num_slots = sizeof(open_archive_subgraph_entry_fields) / sizeof(ArchivableStaticFieldInfo);
> 1618:   assert(p[num_slots - 2].klass_name == NULL, "must have empty slot");
> 1619:   assert(p[num_slots - 1].klass_name == NULL, "must have empty slot");

Should the first assert be the following?

`assert(p[num_slots - 1].field_name == NULL, "must have empty slot");`

src/hotspot/share/classfile/systemDictionary.cpp line 1056:

> 1054:       assert(HeapShared::is_a_test_class_in_unnamed_module(ik),
> 1055:              "Loading non-bootstrap classes before the module system is initialized");
> 1056:     }

Should there be an else case with the original assert?

`assert(class_loader.is_null(), "sanity");`

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

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

From jianglizhou at google.com  Thu Sep  1 19:51:24 2022
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 1 Sep 2022 12:51:24 -0700
Subject: RFC: Change CDS JAR file validation
In-Reply-To: <d4a49ea8-04c1-6e4d-8f2c-e5a85614b952@oracle.com>
References: <d4a49ea8-04c1-6e4d-8f2c-e5a85614b952@oracle.com>
Message-ID: <CALrW1jzNJvGRg6C0ULjhjvy0DWLRxk7ba5LLALagSmX=ZAX2mg@mail.gmail.com>

When utilizing CDS for tools in a cloud environment a few years back,
we ran into the path checking issue. One of the main problems that we
observed was that the mtime based check was not reliable. Internally,
we've explored a few potential solutions. One of suggested ideas was
to compute a checksum of the jar file and store the value in the zip
central directory. Runtime can then validate the checksum. That can be
reliable. It may require specification changes.

Another approach is to provide a runtime flag (e.g.
-XX:+|-ValidateSharedClassPaths), which can be used to disable the
problematic jar path checking in use cases where it is safe to do so.
This is the approach that we have been using for tools that use CDS.
The tools' JAR files and CDS images are built and released together.
As the release progresses guarantee the compatibility between the JAR
file and the CDS archive in these kinds of usages, we can safely
disable the corresponding path checking. It also minimizes the related
overhead. I'd like to contribute the related patch in the short term.

Thanks,
Jiangli

On Wed, Aug 31, 2022 at 9:47 PM Ioi Lam <ioi.lam at oracle.com> wrote:
>
> Proposal Summary:
>
> Use a digest of a JAR file to detect if the file has changed
>
>
> Background
> ==========
>
> CDS is in effect a caching mechanism -- it needs to make sure that the
> InstanceKlasses stored in the archive are the same as those parsed from
> classfiles.
>
> To do this, we archive only the classes from (a) the JDK's modules image
> file and (b) JAR files. We don't archive classes in directories since
> it's difficult to check if the contents of a directory have changed.
>
> At runtime, we assume that (a) didn't change, since we require the exact
> same JDK build to be used.
>
> For (b) we currently do this:
>
> (1) Check that -classpath and -Xbootclasspath (absolute paths) are
> identical between run time and dump time.
> (2) For each JAR file in cp and bcp, check if its size and modification
> time has changed.
> (3) (Something similar happens with the module path ....)
>
> We have used this scheme for almost a decade. Note that we avoid reading
> the JAR files as that may slow down start-up time on old spinning disks.
> However, as most work-loads run on SSDs now, I believe this is no longer
> a concern.
>
> Recently, we are seeing problems when people deploy CDS inside containers:
>
> For (1) the file system structure may different between run time and
> dump time. We can kludge around this problem by using relative paths
> instead of absolute paths, but this will make the existing code even
> more complicated.
>
> For (2) when deploying the app, it may not be easy to keep the
> modification time unchanged (see JDK-8284692).
>
>
> Proposal
> ========
>
> For (1) - don't not compare directory name anymore. Only check that the
> filename is the same:
>
> E.g.
>
> Dump:
>      java -Xshare:dump -cp dir1/Foo.jar:dir2/Bar.jar ..
>
> Run:
>      java -cp dir1/Foo.jar:dir2/Bar.jar ...     [OK]
> java -cp Foo.jar:Bar.jar ...               [OK]
>      java -cp Foo.jar:Bxx.jar ... [Fail - changed from Bar.jar to Bxx.jar]
>
> For (2)
>
> - Check that file size has not changed.
> - Compute a digest of the file. Check that this has not changed.
>
>
> Digest
> ======
>
> The purpose is not for security or (malicious) tamper detection. It's
> for guarding against innocent mistakes (forgot to regenerate CDS archive
> after JAR files have been updated). Therefore, we don't need to run an
> expensive digest like MD5.
>
> Instead, it should be enough to just do a quick XOR digest of the first
> 128 bytes of the JAR file. Since this part usually contains the
> META-INF/ directory and its modification time. So it effectively
> contains the time when this JAR file was created. The timestamp seems to
> have a 2 second resolution:
>
> $ while true; do jar cfm foo.jar MANIFEST.MF HelloWorld.class ; head -c
> 128 foo.jar | cksum; sleep 2; done
> 3803507028 128
> 1857545662 128
> 916098721 128
> 3740087168 128
> 2260752543 128
> 3257546723 128
> 2584173820 128
> ...
>
>
> Advantage:
>
> - Make it easier to deploy CDS archive (fewer false negatives)
> - Simplify logic in the CDS code
>
> Risks:
>
> - Opening every JAR file may cause a slow down if you have lots of JARs
> in the classpath running on a slow file system.
>

From coleenp at openjdk.org  Thu Sep  1 20:20:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 20:20:08 GMT
Subject: RFR: 8291736: find_method_handle_intrinsic leaks Method* [v4]
In-Reply-To: <gcgz_vbe4ZWjs05xy-uP7t4RGYQbc9S-iSx7gno8rn0=.0ec3f961-64b0-4db1-9e13-8caa0cf89359@github.com>
References: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
 <W_G-7g0kAsZ3GhV8Tj73Jby0xDGayuAffLk_Xo3hCho=.d68d1bd0-f4af-41d5-9c1e-ac7e96e3cdfb@github.com>
 <nvTJ7hqqdlBAbNs8jo7SQXTi-XmEZuXhyiwTb1qgd00=.9d6f19e8-c9b7-45cc-a422-acb2f69cb9f0@github.com>
 <3_yOMnwYvjL4AjJFodW2TvWgW8sMbbAIRyq05o8queU=.600ead46-7ea0-454c-b3a3-3bc6925af79d@github.com>
 <f52ZOodQC96w15kqEIbuq9gzXdn3lGGde3VeUMlbWFg=.c19f03a1-cab6-45d6-81b5-93a01d17f194@github.com>
 <-Fw3NKgGxYOgZcX_w408mst9Ht1QyE6rr4bzXc7UD6Y=.7019579e-c511-4cfe-acaf-b27d8a040fd6@github.com>
 <BylwK3lKu8czD81I87SagboToLTEwMzZS7Y7jBdGWRo=.9d15f4ae-4ff1-4710-95f5-23b71bd324c5@github.com>
 <gcgz_vbe4ZWjs05xy-uP7t4RGYQbc9S-iSx7gno8rn0=.0ec3f961-64b0-4db1-9e13-8caa0cf89359@github.com>
Message-ID: <BhwacSQxQlgWXxW5TCiXPT7KM98qZF-PlfxVktm1hBo=.316490a9-9615-4518-bcbc-d8a23be20dc1@github.com>

On Thu, 1 Sep 2022 06:42:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The problem with the original code was the ranking and multi-purpose use of the SystemDictionary_lock.  Creating the adapters takes out a lock whose ranking is above SystemDictionary_lock.  Also the tables (and lock for the tables) were shared with code that could call Java code for calling Java to create MethodType, so that code had to release the lock.  Leaking the java.lang.invoke.MethodType is ok because it'll be GC'd.
>> 
>> We've leaked the Method* and adapter for many years now, maybe it's fine to keep leaking it and I should just close this and not try to fix it.
>> 
>> The case of throwing exceptions inside Mutex locked regions is something I thought we have all over the source code.  I couldn't find any explicit calls, but the pattern of doing metaspace allocation inside of a MutexLocker is in enough places that adding an   assert(!thread->owns_locks(), "must release all locks when possibly throwing exceptions"); during in the TRAPS version of Metaspace::allocate() fails immediately.
>> 
>> But it may be that the OOM for Metaspace allocation failure doesn't call into Java for constructing the object and this part is fine.
>
> Right, as per our side-bar discussion, while the general rule is "no throwing exceptions while holding a VM mutex/monitor" it seems that it is safe to only throw OutOfMemoryError because `Universe::gen_out_of_memory_error` doesn't execute any Java code. It either uses one of the pre-allocated OOME instances (if available) and fills in the stacktrace, or else (or in case of secondary OOM) it uses the pre-allocated stackless singleton instance.  This should be documented somewhere of course (and perhaps even programmatically verified somehow `NoJavaCodeVerifier`? :) )
> 
> Also whilst the lower-level code makes it somewhat clear that the only exception that can arise is the metaspace OOME, it is not at all clear just by looking at a callsite like:
> 
> methodHandle m = Method::make_method_handle_intrinsic(iid, signature, CHECK_NULL);
> 
> so perhaps we even need additional macros like CHECK_OOM to verify only OOME can be thrown? (Not in this PR.)

I added a comment above the make_method_handle_intrinsic call about why it's ok to call inside a locked region, and agree that we need better checking for the ability to run Java code from all paths with possible exceptions.  I'm not sure how to do that yet but we should file an RFE.

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

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

From kvn at openjdk.org  Thu Sep  1 20:21:29 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Sep 2022 20:21:29 GMT
Subject: RFR: 8292584: assert(cb != __null) failed: must be with
 -XX:-Inline [v6]
In-Reply-To: <fTXgil2HOi4SFVndykfmeQVLK-BP_NesTWFBtNWOTzI=.96217b77-f8d6-458e-969e-480b0a95e238@github.com>
References: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
 <fTXgil2HOi4SFVndykfmeQVLK-BP_NesTWFBtNWOTzI=.96217b77-f8d6-458e-969e-480b0a95e238@github.com>
Message-ID: <s-JPttE83fd-1yZr81WnoXJ-09w-WVBfWv5Lqx0Xw3Y=.ac8a0922-38b2-4423-a7a8-4d4a8e8b805b@github.com>

On Thu, 1 Sep 2022 03:02:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable.  The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame.  Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment.  The easiest fix is to undo what the c2i adapter might have done.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - merge fix
>  - Merge master
>  - fix build failures
>  - fix zero build
>  - cleanup
>  - fix failed assert
>  - version 2, make doYield a native intrinsic like enterSpecial
>  - fix generate_Continuation_doYield_entry

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From dlong at openjdk.org  Thu Sep  1 20:21:29 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Sep 2022 20:21:29 GMT
Subject: RFR: 8292584: assert(cb != __null) failed: must be with
 -XX:-Inline [v6]
In-Reply-To: <fTXgil2HOi4SFVndykfmeQVLK-BP_NesTWFBtNWOTzI=.96217b77-f8d6-458e-969e-480b0a95e238@github.com>
References: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
 <fTXgil2HOi4SFVndykfmeQVLK-BP_NesTWFBtNWOTzI=.96217b77-f8d6-458e-969e-480b0a95e238@github.com>
Message-ID: <KhQWyzavv1bYFjqKvuBxBvLZbjk-sfNU8i0yt21XPp8=.8999370f-8bcf-4cee-9348-c1e246098034@github.com>

On Thu, 1 Sep 2022 03:02:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable.  The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame.  Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment.  The easiest fix is to undo what the c2i adapter might have done.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - merge fix
>  - Merge master
>  - fix build failures
>  - fix zero build
>  - cleanup
>  - fix failed assert
>  - version 2, make doYield a native intrinsic like enterSpecial
>  - fix generate_Continuation_doYield_entry

Thanks Vladimir.

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

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

From coleenp at openjdk.org  Thu Sep  1 20:21:41 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 20:21:41 GMT
Subject: RFR: 8292916: Streamline LoaderConstraint purging [v3]
In-Reply-To: <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
 <k13LyZuxn0JpdVDey8gubUzjJzbbTfc9XPUkNKY90Hk=.ef114ed1-fa60-46de-a901-1884b5c4852b@github.com>
Message-ID: <ylhCWdnXy86dMGak3rzmEe1pw4E80rH8Yg39fP1Aowc=.7f347194-9a91-41c2-80fd-ac07ad00883f@github.com>

On Thu, 1 Sep 2022 12:44:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
>> 
>> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
>> 
>> Tested with tier1-3 which contains jck tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copy logging rather than passing name to remove_constraint.

Offline, Ioi and talked about this change and it's not correct.  You can have a klass in a constraint get unloaded, but the loader list can then refer to constraints for classes that haven't been resolved with that name, so the constraint should not be deleted in this case.

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

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

From coleenp at openjdk.org  Thu Sep  1 20:21:41 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Sep 2022 20:21:41 GMT
Subject: Withdrawn: 8292916: Streamline LoaderConstraint purging
In-Reply-To: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
References: <MzgUg8H4qOC_H82d4bhOSer_xjfv-J5pq38uPLosiW8=.e83050f5-83ad-41f6-97ab-385ab8c7bdb2@github.com>
Message-ID: <hdcmouZYqqx79yjaJk-ZakJ2kCfSqTlu--MZGqYNnSA=.96a5be3b-1a1c-4920-9dfd-2742e079f84b@github.com>

On Thu, 25 Aug 2022 12:56:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
> 
> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
> 
> Tested with tier1-3 which contains jck tests.

This pull request has been closed without being integrated.

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

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

From dlong at openjdk.org  Thu Sep  1 20:22:48 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Sep 2022 20:22:48 GMT
Subject: Integrated: 8292584: assert(cb != __null) failed: must be with
 -XX:-Inline
In-Reply-To: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
References: <G78SQiJ0NvDxIGsXW0T_Xk_d5P2WP67SIyU6OUDERjE=.cf1a7220-8231-421b-8e13-57ce5384be2a@github.com>
Message-ID: <wJdbKryyrWDRiYDP0q06m6PtXpJpuda9rj5QFIivop0=.a61e99dd-49f0-4570-a171-2358a8150bbb@github.com>

On Tue, 23 Aug 2022 06:53:36 GMT, Dean Long <dlong at openjdk.org> wrote:

> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable.  The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame.  Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment.  The easiest fix is to undo what the c2i adapter might have done.

This pull request has now been integrated.

Changeset: fa68371b
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa68371bb816d797da02e51187955044f835d402
Stats:     586 lines in 48 files changed: 194 ins; 340 del; 52 mod

8292584: assert(cb != __null) failed: must be with -XX:-Inline

Reviewed-by: kvn, rpressler

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

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

From kbarrett at openjdk.org  Thu Sep  1 21:21:21 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 Sep 2022 21:21:21 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v5]
In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
Message-ID: <z8Vk67_dUpTSM2zMR482xj7uPbNxl1yTlL1QiVEC5Ds=.f4bfeb0a-282a-4fb6-a38a-c284f6940baa@github.com>

On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot?
>> 
>> This PR does 3 things:
>> 
>> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot
>> * Adds some new utilities for writing multi-threaded tests.
>> * Adds some tests for MRSW Mutex using these new utilities
>> 
>> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714
>> 
>> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

I don't expect this to be a popular opinion, but the more I think about it
the less I like the direct use of PlatformMonitor here rather than using
Monitor.  The "extra cruft" that comes with Monitor is there for reasons, and
I'm not convinced that bypassing all that is good.

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

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

From iklam at openjdk.org  Fri Sep  2 04:17:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 2 Sep 2022 04:17:59 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v3]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <lSFAGrNaJbHuyb6tCd1AcxMwG2Bn4cARrL0ZVn2Uvos=.fd81911c-9824-4271-b68e-5b0fa58af530@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - clarified assert message
 - @calvinccheung comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10110/files
  - new: https://git.openjdk.org/jdk/pull/10110/files/c8882d1d..50f4a01c

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

  Stats: 11 lines in 3 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10110.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10110/head:pull/10110

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

From iklam at openjdk.org  Fri Sep  2 04:22:48 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 2 Sep 2022 04:22:48 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v4]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <ZbrVYIjFFfzm46rVTW_H-3uvZswpiNpT7aq1n03bXOE=.b6f2f4d8-cabd-49c7-b08a-f5421d38f852@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Use help message suggedted by @calvinccheung

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10110/files
  - new: https://git.openjdk.org/jdk/pull/10110/files/50f4a01c..a8d874a9

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

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

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

From iklam at openjdk.org  Fri Sep  2 04:22:51 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 2 Sep 2022 04:22:51 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v2]
In-Reply-To: <tB9NajK7xzlxjzxMnkf6_StQy1wFeyXyby2ijmfcpyw=.73136649-1f52-40d8-bc2e-3cac41093f78@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3fAN8xa-Y8qB5kL3lBgozmVwwIGIAYnR1ioShlDaufI=.9b7dbfcf-e07b-4e7b-95f2-90943aeef7ca@github.com>
 <tB9NajK7xzlxjzxMnkf6_StQy1wFeyXyby2ijmfcpyw=.73136649-1f52-40d8-bc2e-3cac41093f78@github.com>
Message-ID: <BQ-tn-u8kM1OHVZZ-_ASCT9_fUf_ywQCsZ9hsUW5tJQ=.242c4096-06e1-4517-b8e9-7413d13083d1@github.com>

On Thu, 1 Sep 2022 19:00:18 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 build (gcc spurious warning)
>
> src/hotspot/share/cds/cds_globals.hpp line 78:
> 
>> 76:           "product builds. If specified, the static field named "           \
>> 77:           "\"archivedObjects\" in this class is stored into the CDS "       \
>> 78:           "archive heap")                                                   \
> 
> The ?this class? wasn?t clear to me until I read the test case. I?d suggest something like the following:
> 
> 
> ?The ""archivedObjects" static field of the specified?
> ?class is stored in the CDS archive heap."

Fixed as you suggested.

> src/hotspot/share/cds/heapShared.cpp line 1619:
> 
>> 1617:   int num_slots = sizeof(open_archive_subgraph_entry_fields) / sizeof(ArchivableStaticFieldInfo);
>> 1618:   assert(p[num_slots - 2].klass_name == NULL, "must have empty slot");
>> 1619:   assert(p[num_slots - 1].klass_name == NULL, "must have empty slot");
> 
> Should the first assert be the following?
> 
> `assert(p[num_slots - 1].field_name == NULL, "must have empty slot");`

The first assert actually checks the slot that's patched a few lines below. I updated the assert message.

> src/hotspot/share/classfile/systemDictionary.cpp line 1056:
> 
>> 1054:       assert(HeapShared::is_a_test_class_in_unnamed_module(ik),
>> 1055:              "Loading non-bootstrap classes before the module system is initialized");
>> 1056:     }
> 
> Should there be an else case with the original assert?
> 
> `assert(class_loader.is_null(), "sanity");`

I removed the `assert(class_loader.is_null(), "sanity");` by mistake. I restored it, and also updated the assert message.

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

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

From iklam at openjdk.org  Fri Sep  2 05:52:39 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 2 Sep 2022 05:52:39 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v5]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <qU6HWqIXh8I_Q-YweDxl01da4Fmc2vP40ayKcUo9yVs=.f756239b-03e7-414f-8e8a-47ebfe9ec09c@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed minimal build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10110/files
  - new: https://git.openjdk.org/jdk/pull/10110/files/a8d874a9..aa927043

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

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

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

From aboldtch at openjdk.org  Fri Sep  2 07:42:36 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Sep 2022 07:42:36 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors
Message-ID: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>

>From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.
Options

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

Commit messages:
 - 8293295: Add type check asserts to java_lang_ref_Reference accessors

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

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

From stefank at openjdk.org  Fri Sep  2 07:58:45 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 2 Sep 2022 07:58:45 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors
In-Reply-To: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
Message-ID: <ktT65v265gPnZPZh5mcvyWkviVPQz2ZngNGzbxrm6cs=.3624203e-b205-4e78-bc3c-b76d0abe398c@github.com>

On Fri, 2 Sep 2022 07:37:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.
> Options

Given that "!is_phantom" returns true for FinalReferences, maybe we should change this to explicitly check if the ref is Weak or Soft?

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

Changes requested by stefank (Reviewer).

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

From aboldtch at openjdk.org  Fri Sep  2 08:21:11 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Sep 2022 08:21:11 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors [v2]
In-Reply-To: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
Message-ID: <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>

> From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add is_soft and is_weak

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10139/files
  - new: https://git.openjdk.org/jdk/pull/10139/files/3ecdc926..ae19bf21

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

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

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

From aboldtch at openjdk.org  Fri Sep  2 08:21:11 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Sep 2022 08:21:11 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors [v2]
In-Reply-To: <ktT65v265gPnZPZh5mcvyWkviVPQz2ZngNGzbxrm6cs=.3624203e-b205-4e78-bc3c-b76d0abe398c@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
 <ktT65v265gPnZPZh5mcvyWkviVPQz2ZngNGzbxrm6cs=.3624203e-b205-4e78-bc3c-b76d0abe398c@github.com>
Message-ID: <8Tk062i2C0zQzhAfDBROmNxYrbOD3zeP60qRRTkpZ3Y=.cd80d56b-3610-4d52-a673-75466b0b7f15@github.com>

On Fri, 2 Sep 2022 07:54:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Given that "!is_phantom" returns true for FinalReferences, maybe we should change this to explicitly check if the ref is Weak or Soft?

Added `is_weak` and `is_soft` to make it more correct with respect to `FinalReference`. This will also be more correct if a `REF_NONE` ever finds its way into these accessors.

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

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

From xliu at openjdk.org  Fri Sep  2 08:23:43 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 2 Sep 2022 08:23:43 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter
In-Reply-To: <mMGWjNvRIB-RDI3hstT0uTYQhQLazldgKq-i9DSfK8g=.2a643286-3773-4c17-8de4-d0f3b1969e75@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <mMGWjNvRIB-RDI3hstT0uTYQhQLazldgKq-i9DSfK8g=.2a643286-3773-4c17-8de4-d0f3b1969e75@github.com>
Message-ID: <rSr9Z7fz9463HdSNircS86ShoESniZEUO-tItkjvVkw=.e3cbe01a-d07a-4fb8-8fe8-001ec8bf076a@github.com>

On Wed, 31 Aug 2022 13:51:22 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 81:
> 
>> 79: const LogDecorations& AsyncLogWriter::None = LogDecorations(LogLevel::Warning, LogTagSetMapping<LogTag::__NO_TAG>::tagset(),
>> 80:                                       LogDecorators::None);
>> 81: // Note: there is an initializer order issue here. C++ cannot guarantee that 'None' is initialized before Token!
> 
> Can we avoid initializing these like this then? What happens if our expectations are not fulfilled some day in the future? I've been bit by bugs caused by this before, not very fun. Is there a reason they can't be initialized in AsyncLogWriter::initialize() for example?
> 
> Context for the curious:
> 
> https://en.cppreference.com/w/cpp/language/initialization
> 
> https://isocpp.org/wiki/faq/ctors#static-init-order
> 
> To be pedantic: I believe that None is guaranteed to be initialized before Token, but the LogTagSet which None is assigned to is not guaranteed to be initialized (because they're part of two different compilation units).

Sorry, this comment was misleading. I left it as a reminder. I mean c++ can't guarantee to initialize None and Token before `LogDecorators::None` is initialized. Like you said, LogDecorators::None is defined in another compilation unit. 

The reason it's right because `LogDecorators::None` is expected to be zero anyway. It's in bss section. That's why I feel it's tricky. I will change this part!

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

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

From stefank at openjdk.org  Fri Sep  2 09:17:49 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 2 Sep 2022 09:17:49 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors [v2]
In-Reply-To: <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
 <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>
Message-ID: <8NP9nqOewBF_0uGJKzlCtOBAXpdk7aRRa4-4YneWwcQ=.6940ea98-6d8e-414e-9fba-178a2f4ea1b0@github.com>

On Fri, 2 Sep 2022 08:21:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add is_soft and is_weak

Looks good!

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

Marked as reviewed by stefank (Reviewer).

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

From stuefe at openjdk.org  Fri Sep  2 09:29:39 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Sep 2022 09:29:39 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter
In-Reply-To: <Td5wbnvzmnW8OUKiAnti_VScVhqmKQHUWd_9wGmt6EE=.e92a5101-eca0-487a-9808-8d70c8d83db5@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <mMGWjNvRIB-RDI3hstT0uTYQhQLazldgKq-i9DSfK8g=.2a643286-3773-4c17-8de4-d0f3b1969e75@github.com>
 <ZnnKGLnud8fg61KvW34LyLMOrUTZDXmgWktBtGniXls=.f6421b94-37f9-493e-910c-d47e4a6681fc@github.com>
 <Td5wbnvzmnW8OUKiAnti_VScVhqmKQHUWd_9wGmt6EE=.e92a5101-eca0-487a-9808-8d70c8d83db5@github.com>
Message-ID: <BOV50L5VWfSATLNnMAh7ulyMXADDU3XtaTxYOcYA2OI=.a591d6d9-cae4-475a-b1cc-d4655d34b110@github.com>

On Wed, 31 Aug 2022 18:12:09 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> I have no idea how to handle the error that malloc returns NULL in ctor. Maybe I am paranoid. glibc/malloc rarely fails because it maps but not commit a memory segment.  We also define the constraint of AsyncLogBufferSize in globals.hpp.
>
> You're right, I forgot how impossible that case is.  Being paranoid with this is fine, imho.

Probably extremely rare, since argument parsing needs C-heap too, for malloc=NULL to hit right here. Not impossible though (limits, sbrk exhausted, etc). Note that we have other libcs too.

But I agree with @jdksjolen original remark. Buffer managing its memory would be more straightforward. No need to handle malloc errors if you just use NEW_C_HEAP_ARRAY and let it fatal out in case of an OOM. Its what we do all over hotspot. Would also save you the ugly cast (why do C++ casts have to be so verbose..).

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

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

From kbarrett at openjdk.org  Fri Sep  2 11:54:43 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Sep 2022 11:54:43 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors [v2]
In-Reply-To: <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
 <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>
Message-ID: <pSAiCjW-p7GjW_0JVlAmFF_LgqpwgYj6zvoecGOq1oo=.844d4436-6e5c-498b-82c3-d9b310ba41e9@github.com>

On Fri, 2 Sep 2022 08:21:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add is_soft and is_weak

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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

From coleenp at openjdk.org  Fri Sep  2 14:49:14 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Sep 2022 14:49:14 GMT
Subject: RFR: 8293315: Add back logging for Placeholders
Message-ID: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>

I lost some information in the logging code for PlaceholderTable that I really want when I converted it to use a ResourceHashtable, so this minor patch adds it back.
Tested locally with -Xlog:class+load+placeholders=trace, tier1 in progress.

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

Commit messages:
 - 8293315: Add back logging for Placeholders

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

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

From iklam at openjdk.org  Fri Sep  2 17:40:40 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 2 Sep 2022 17:40:40 GMT
Subject: RFR: 8293315: Add back logging for Placeholders
In-Reply-To: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>
References: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>
Message-ID: <8vrRWBQPiMx_iUsT9zlY-cgiOpM1qAbV-9dxQrrnHeM=.dc2aac1d-59f9-43c2-aef1-80fbb939efea@github.com>

On Fri, 2 Sep 2022 14:23:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I lost some information in the logging code for PlaceholderTable that I really want when I converted it to use a ResourceHashtable, so this minor patch adds it back.
> Tested locally with -Xlog:class+load+placeholders=trace, and tier1.

Looks good and trivial.

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

Marked as reviewed by iklam (Reviewer).

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

From coleenp at openjdk.org  Fri Sep  2 17:55:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Sep 2022 17:55:08 GMT
Subject: RFR: 8293315: Add back logging for Placeholders
In-Reply-To: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>
References: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>
Message-ID: <96Ippgs6z4dAMXwCS8XsBOLinsuQSy8qtXg-2CTUWQI=.8c79acde-ae62-439b-8eb2-9ae5a0a783fc@github.com>

On Fri, 2 Sep 2022 14:23:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I lost some information in the logging code for PlaceholderTable that I really want when I converted it to use a ResourceHashtable, so this minor patch adds it back.
> Tested locally with -Xlog:class+load+placeholders=trace, and tier1.

Thanks for the review, Ioi.

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

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

From coleenp at openjdk.org  Fri Sep  2 17:55:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Sep 2022 17:55:08 GMT
Subject: Integrated: 8293315: Add back logging for Placeholders
In-Reply-To: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>
References: <zBU-SUlEibKbnRkrgpbVnijASfc8zuDcO8JEVLYAa2A=.82663736-4e90-4321-8abb-5e09d6352f8f@github.com>
Message-ID: <pfEeFQuBDrehUg15onyj_9PAcSGM_jEey3S8E94gYuY=.ce8a525a-0d3e-4521-8c21-4b1869bd9b12@github.com>

On Fri, 2 Sep 2022 14:23:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I lost some information in the logging code for PlaceholderTable that I really want when I converted it to use a ResourceHashtable, so this minor patch adds it back.
> Tested locally with -Xlog:class+load+placeholders=trace, and tier1.

This pull request has now been integrated.

Changeset: 83a34086
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83a34086bc841b4ccf64b1817561f73b68b585eb
Stats:     9 lines in 2 files changed: 0 ins; 0 del; 9 mod

8293315: Add back logging for Placeholders

Reviewed-by: iklam

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

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

From coleenp at openjdk.org  Fri Sep  2 18:07:43 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Sep 2022 18:07:43 GMT
Subject: RFR: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors [v2]
In-Reply-To: <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
 <a1TZ7VYRraR6RYyMEoFo3L9v-rRDq1g7khfsya90jtI=.9ae44178-95ae-4b18-b228-b8e6aa29a20e@github.com>
Message-ID: <phtc_KJmS9OUfSX2xZe5u4pxbG3GfUdtwQ1xpSrC0dM=.c6f09bf6-f741-40bd-b2c4-348f01f3f642@github.com>

On Fri, 2 Sep 2022 08:21:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add is_soft and is_weak

Marked as reviewed by coleenp (Reviewer).

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

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

From coleenp at openjdk.org  Fri Sep  2 19:29:06 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Sep 2022 19:29:06 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v5]
In-Reply-To: <qU6HWqIXh8I_Q-YweDxl01da4Fmc2vP40ayKcUo9yVs=.f756239b-03e7-414f-8e8a-47ebfe9ec09c@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <qU6HWqIXh8I_Q-YweDxl01da4Fmc2vP40ayKcUo9yVs=.f756239b-03e7-414f-8e8a-47ebfe9ec09c@github.com>
Message-ID: <hbeEMneS_uNQHVKoqzI9QcnDqLjMtzaAif_jTN7m6Io=.ef62b789-3a67-4ae2-88b2-cec836110540@github.com>

On Fri, 2 Sep 2022 05:52:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
>> 
>> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
>> 
>> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
>> 
>> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
>> 
>> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
>> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed minimal build

src/hotspot/share/cds/cds_globals.hpp line 78:

> 76:           "product builds. The \"archivedObjects\" static field "           \
> 77:           "of the specified class is stored in the CDS archive heap")       \
> 78:                                                                             \

"Not available in product builds" is redundant with the flag definition.

src/hotspot/share/cds/heapShared.cpp line 1542:

> 1540:     }
> 1541: 
> 1542:     Klass* k = SystemDictionary::resolve_or_fail(klass_name, true, THREAD);

Is this all only needed for #ifndef PRODUCT ?? if so you can put a ResourceMark unconditionally here because it seems like one might be needed.

src/hotspot/share/cds/heapShared.cpp line 1663:

> 1661:         // otherwise it must be in (B).
> 1662:         for (int j = 0; j < name->utf8_length(); j++) {
> 1663:           if (name->char_at(j) == '/') {

Can you use strchr instead?

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

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

From coleenp at openjdk.org  Fri Sep  2 19:29:06 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Sep 2022 19:29:06 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v5]
In-Reply-To: <hbeEMneS_uNQHVKoqzI9QcnDqLjMtzaAif_jTN7m6Io=.ef62b789-3a67-4ae2-88b2-cec836110540@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <qU6HWqIXh8I_Q-YweDxl01da4Fmc2vP40ayKcUo9yVs=.f756239b-03e7-414f-8e8a-47ebfe9ec09c@github.com>
 <hbeEMneS_uNQHVKoqzI9QcnDqLjMtzaAif_jTN7m6Io=.ef62b789-3a67-4ae2-88b2-cec836110540@github.com>
Message-ID: <a6GgZF022XfCcZ7QhglYb-1lJj0D1Ac8lbNgBgst1BU=.c10a4cf8-683c-41f6-ade5-441bc3fb77a1@github.com>

On Fri, 2 Sep 2022 19:11:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed minimal build
>
> src/hotspot/share/cds/cds_globals.hpp line 78:
> 
>> 76:           "product builds. The \"archivedObjects\" static field "           \
>> 77:           "of the specified class is stored in the CDS archive heap")       \
>> 78:                                                                             \
> 
> "Not available in product builds" is redundant with the flag definition.

How about "The static field named "archivedObjects" of the specified class is stored in the CDS archive heap.

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

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

From xliu at openjdk.org  Fri Sep  2 19:48:43 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 2 Sep 2022 19:48:43 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter
In-Reply-To: <BOV50L5VWfSATLNnMAh7ulyMXADDU3XtaTxYOcYA2OI=.a591d6d9-cae4-475a-b1cc-d4655d34b110@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <mMGWjNvRIB-RDI3hstT0uTYQhQLazldgKq-i9DSfK8g=.2a643286-3773-4c17-8de4-d0f3b1969e75@github.com>
 <ZnnKGLnud8fg61KvW34LyLMOrUTZDXmgWktBtGniXls=.f6421b94-37f9-493e-910c-d47e4a6681fc@github.com>
 <Td5wbnvzmnW8OUKiAnti_VScVhqmKQHUWd_9wGmt6EE=.e92a5101-eca0-487a-9808-8d70c8d83db5@github.com>
 <BOV50L5VWfSATLNnMAh7ulyMXADDU3XtaTxYOcYA2OI=.a591d6d9-cae4-475a-b1cc-d4655d34b110@github.com>
Message-ID: <bmBpusvNwlWr05pCFprBx_itD-OwxrXX7OrgzDRqUn0=.9afd1c5a-ee13-47cb-abda-daa9157b1165@github.com>

On Fri, 2 Sep 2022 09:27:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> You're right, I forgot how impossible that case is.  Being paranoid with this is fine, imho.
>
> Probably extremely rare, since argument parsing needs C-heap too, for malloc=NULL to hit right here. Not impossible though (limits, sbrk exhausted, etc). Note that we have other libcs too.
> 
> But I agree with @jdksjolen original remark. Buffer managing its memory would be more straightforward. No need to handle malloc errors if you just use NEW_C_HEAP_ARRAY and let it fatal out in case of an OOM. Its what we do all over hotspot. Would also save you the ugly cast (why do C++ casts have to be so verbose..).

okay. thanks. I will update this.

I prefer to detect this allocation failure and fall back to synchronous logging. This is for resource-constrained java. '-Xlog:async' shouldn't contribute a runtime error.

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

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

From dholmes at openjdk.org  Fri Sep  2 20:22:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Sep 2022 20:22:49 GMT
Subject: RFR: 8291736: find_method_handle_intrinsic leaks Method* [v4]
In-Reply-To: <nJOCIGdD6TSz_RSgWXpupKT8D3U2KoZpNdl9hiDK4FA=.cadf61d6-8c7a-477a-b642-2cd1242856ac@github.com>
References: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
 <nJOCIGdD6TSz_RSgWXpupKT8D3U2KoZpNdl9hiDK4FA=.cadf61d6-8c7a-477a-b642-2cd1242856ac@github.com>
Message-ID: <pKnQhpA0Pdi4-A_LEvtjbfNQj2OGPrlgjBBbirxfVHw=.80966b83-f55b-4945-a5b1-723fde6b3113@github.com>

On Thu, 1 Sep 2022 15:01:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> As part of the SymbolPropertyTable conversion, we noticed that threads could race to add the Method entry to the table, and the loser wasn't deleted.  This change locks the InvokeMethodTable_lock through the Method creation so that it's not leaked.  See bug for details, but this was performance tested with our general suite of performance tests to show no significant differences.
>> Also tested with tier1-3, and previously 4-7 with SymbolPropertyTable conversion patch.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

No further comments from me.

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

Marked as reviewed by dholmes (Reviewer).

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

From xliu at openjdk.org  Fri Sep  2 22:35:41 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 2 Sep 2022 22:35:41 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  update according to feedbacks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/1e7b1e90..1950a63d

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

  Stats: 48 lines in 4 files changed: 16 ins; 17 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10092.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10092/head:pull/10092

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

From xliu at openjdk.org  Fri Sep  2 22:54:51 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 2 Sep 2022 22:54:51 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <9aSeL1bH5qe3SLOSkbqj2U2l3uZXYhOK1m2yMN_-4As=.15d3f963-8cd1-4a88-a408-ec58cb96cbc2@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <mMGWjNvRIB-RDI3hstT0uTYQhQLazldgKq-i9DSfK8g=.2a643286-3773-4c17-8de4-d0f3b1969e75@github.com>
 <9aSeL1bH5qe3SLOSkbqj2U2l3uZXYhOK1m2yMN_-4As=.15d3f963-8cd1-4a88-a408-ec58cb96cbc2@github.com>
Message-ID: <l1LEtEcn9vfplnL_itdM-iiNfk5cSm4UbadEvKksCQ8=.752895ca-bb39-492b-b0b3-429af67c2b34@github.com>

On Wed, 31 Aug 2022 17:53:24 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.hpp line 98:
>> 
>>> 96:     bool push_back(const AsyncLogMessage& msg);
>>> 97: 
>>> 98:     // for testing-only!
>> 
>> We typically allow test fixture classes to be declared `friend`s to the classes they test. This allows you to move testing functions to the testing code.
>
> make sense!

I made `AsyncLogWriter::throttle_buffers' private.

I don't think it's necessary to declare `friend class AsyncLogWriter` here in class Buffer. Buffer is a private nested class and we can't construct it outside, so I think it's okay to leave `set_capacity` public here.

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

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

From duke at openjdk.org  Sat Sep  3 15:12:03 2022
From: duke at openjdk.org (xpbob)
Date: Sat, 3 Sep 2022 15:12:03 GMT
Subject: RFR: 8293340: [cleanup] Remove unused _code in
 TemplateInterpreterGenerator
Message-ID: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>

Hi all,
The _code arg in TemplateInterpreterGenerator is unused 
Remove `_code`
Thanks.

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

Commit messages:
 - 8293340: [cleanup] Remove unused _code in TemplateInterpreterGenerator

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

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

From duke at openjdk.org  Sat Sep  3 15:24:30 2022
From: duke at openjdk.org (xpbob)
Date: Sat, 3 Sep 2022 15:24:30 GMT
Subject: RFR: 8293340: [cleanup] Remove unused _code in
 TemplateInterpreterGenerator [v2]
In-Reply-To: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
References: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
Message-ID: <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>

> Hi all,
> The _code arg in TemplateInterpreterGenerator is unused 
> Remove `_code`
> Thanks.

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

  add zeroInterpreter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10156/files
  - new: https://git.openjdk.org/jdk/pull/10156/files/94463a9d..1252cf38

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

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

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

From jiefu at openjdk.org  Mon Sep  5 01:35:19 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 5 Sep 2022 01:35:19 GMT
Subject: RFR: 8293340: [cleanup] Remove unused _code in
 TemplateInterpreterGenerator [v2]
In-Reply-To: <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
References: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
 <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
Message-ID: <nuI_XqD8MYzS_456c-AWYk4zs6sB6XK8F0QHjPHDOfA=.b170f906-12be-4f82-b742-c67d23bea820@github.com>

On Sat, 3 Sep 2022 15:24:30 GMT, xpbob <duke at openjdk.org> wrote:

>> Hi all,
>> The _code arg in TemplateInterpreterGenerator is unused 
>> Remove `_code`
>> Thanks.
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add zeroInterpreter

LGTM

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

Marked as reviewed by jiefu (Reviewer).

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

From stuefe at openjdk.org  Mon Sep  5 07:37:06 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 07:37:06 GMT
Subject: RFR: JDK-8293344: JDK-8242181 broke stack printing for non-attached
 threads
Message-ID: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>

https://bugs.openjdk.org/browse/JDK-8242181 gave us source infos in call stacks on Linux, which is really nice, but it made stack printing more vulnerable. We now require Thread::current, which makes stack printing fail and crash in non-attached threads. Causes truncated or missing stacks in hs-err file resp. crashes if stack printing is used outside error reporting.

I tested the fix manually.

I also am working on a testing facility for cases like these, which I will introduce in a separate RFE (see https://bugs.openjdk.org/browse/JDK-8293346).

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

Commit messages:
 - JDK-8293344-stack-printing-nonattached-threads-broken

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

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

From stuefe at openjdk.org  Mon Sep  5 07:37:06 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 07:37:06 GMT
Subject: RFR: JDK-8293344: JDK-8242181 broke stack printing for
 non-attached threads
In-Reply-To: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
References: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
Message-ID: <Lf6QXfIv3mf8jLC7UqFMFtqClVFmO3OWpyB2fTDetXY=.2c4aeb95-6fc7-4425-b3b2-df44ffcac8e5@github.com>

On Mon, 5 Sep 2022 07:12:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8242181 gave us source infos in call stacks on Linux, which is really nice, but it made stack printing more vulnerable. We now require Thread::current, which makes stack printing fail and crash in non-attached threads. Causes truncated or missing stacks in hs-err file resp. crashes if stack printing is used outside error reporting.
> 
> I tested the fix manually.
> 
> I also am working on a testing facility for cases like these, which I will introduce in a separate RFE (see https://bugs.openjdk.org/browse/JDK-8293346).

pinging @chhagedorn

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

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

From aboldtch at openjdk.org  Mon Sep  5 08:36:50 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 08:36:50 GMT
Subject: Integrated: 8293295: Add type check asserts to java_lang_ref_Reference
 accessors
In-Reply-To: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
References: <DrP7oadsp_p_n2VcKhu8eh29OE_6zvkkgEGeMXJqK1E=.7edae40f-604e-44da-9492-9631967ff296@github.com>
Message-ID: <iJqSxW9ockjoj0vtMs9qo3EK2Upx_Cy3Bz2pMd-S5wA=.61a19f50-1eff-47b5-bf3d-73f77e27eb54@github.com>

On Fri, 2 Sep 2022 07:37:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> From a discussion in [JDK-8293207](https://bugs.openjdk.org/browse/JDK-8293207) / #10117 it was brought up that the Weak/Soft and Phantom specific accessor in java_lang_ref_Reference does not assert that the type is valid.
> 
> Testing: Oracle platforms tier 1-4

This pull request has now been integrated.

Changeset: 32f4dc84
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Committer: Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32f4dc84037696f664114e40357bca66337c6178
Stats:     14 lines in 2 files changed: 14 ins; 0 del; 0 mod

8293295: Add type check asserts to java_lang_ref_Reference accessors

Reviewed-by: stefank, kbarrett, coleenp

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

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

From chagedorn at openjdk.org  Mon Sep  5 11:41:43 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 5 Sep 2022 11:41:43 GMT
Subject: RFR: JDK-8293344: JDK-8242181 broke stack printing for
 non-attached threads
In-Reply-To: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
References: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
Message-ID: <n1cLvrbiyL1BLosfSO_hJJFnrchKxoD2FPRkartkcew=.1b9a21a2-dd8b-40d6-b6b1-6307ea3c9089@github.com>

On Mon, 5 Sep 2022 07:12:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8242181 gave us source infos in call stacks on Linux, which is really nice, but it made stack printing more vulnerable. We now require Thread::current, which makes stack printing fail and crash in non-attached threads. Causes truncated or missing stacks in hs-err file resp. crashes if stack printing is used outside error reporting.
> 
> I tested the fix manually.
> 
> I also am working on a testing facility for cases like these, which I will introduce in a separate RFE (see https://bugs.openjdk.org/browse/JDK-8293346).

Looks good, thanks for fixing this! I guess I've missed that behind the PPC `ifdef`.

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

Marked as reviewed by chagedorn (Reviewer).

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

From mdoerr at openjdk.org  Mon Sep  5 12:41:50 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Sep 2022 12:41:50 GMT
Subject: RFR: JDK-8293344: JDK-8242181 broke stack printing for
 non-attached threads
In-Reply-To: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
References: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
Message-ID: <GMoZcLV4yTT5LiJD5cJb8PftVpstEbwmCsfcuHf9ykw=.4ea8490a-86f8-4048-afac-7cae8d648d76@github.com>

On Mon, 5 Sep 2022 07:12:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8242181 gave us source infos in call stacks on Linux, which is really nice, but it made stack printing more vulnerable. We now require Thread::current, which makes stack printing fail and crash in non-attached threads. Causes truncated or missing stacks in hs-err file resp. crashes if stack printing is used outside error reporting.
> 
> I tested the fix manually.
> 
> I also am working on a testing facility for cases like these, which I will introduce in a separate RFE (see https://bugs.openjdk.org/browse/JDK-8293346).

LGTM. Thanks for fixing!

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

Marked as reviewed by mdoerr (Reviewer).

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

From stuefe at openjdk.org  Mon Sep  5 13:09:38 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 13:09:38 GMT
Subject: RFR: JDK-8293344: JDK-8242181 broke stack printing for
 non-attached threads
In-Reply-To: <n1cLvrbiyL1BLosfSO_hJJFnrchKxoD2FPRkartkcew=.1b9a21a2-dd8b-40d6-b6b1-6307ea3c9089@github.com>
References: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
 <n1cLvrbiyL1BLosfSO_hJJFnrchKxoD2FPRkartkcew=.1b9a21a2-dd8b-40d6-b6b1-6307ea3c9089@github.com>
Message-ID: <MbnSNBAjTKW6EoQNz6Q52LMp33ob71t4xSp-x2lzl_s=.9c838490-0045-4bb6-9a27-c73f32321f14@github.com>

On Mon, 5 Sep 2022 11:39:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8242181 gave us source infos in call stacks on Linux, which is really nice, but it made stack printing more vulnerable. We now require Thread::current, which makes stack printing fail and crash in non-attached threads. Causes truncated or missing stacks in hs-err file resp. crashes if stack printing is used outside error reporting.
>> 
>> I tested the fix manually.
>> 
>> I also am working on a testing facility for cases like these, which I will introduce in a separate RFE (see https://bugs.openjdk.org/browse/JDK-8293346).
>
> Looks good, thanks for fixing this! I guess I've missed that behind the PPC `ifdef`.

Thanks @chhagedorn and @TheRealMDoerr !

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

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

From stuefe at openjdk.org  Mon Sep  5 13:11:01 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 13:11:01 GMT
Subject: Integrated: JDK-8293344: JDK-8242181 broke stack printing for
 non-attached threads
In-Reply-To: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
References: <7NHnxglTfB472cMw4pU9O9nFOdNlroul6GiH96-fq5Q=.2888df6a-1ecf-4a98-a26e-525677d50e3a@github.com>
Message-ID: <SxPokc6jxU2a0XUsfhgw1DET-dsgnaZEvmBmwVYkwho=.40c7b6a3-704d-459f-8e32-8c0e1b49c90f@github.com>

On Mon, 5 Sep 2022 07:12:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8242181 gave us source infos in call stacks on Linux, which is really nice, but it made stack printing more vulnerable. We now require Thread::current, which makes stack printing fail and crash in non-attached threads. Causes truncated or missing stacks in hs-err file resp. crashes if stack printing is used outside error reporting.
> 
> I tested the fix manually.
> 
> I also am working on a testing facility for cases like these, which I will introduce in a separate RFE (see https://bugs.openjdk.org/browse/JDK-8293346).

This pull request has now been integrated.

Changeset: d4e3e695
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4e3e69505db1b114afec2f6a61acf1261a8e69c
Stats:     6 lines in 1 file changed: 3 ins; 2 del; 1 mod

8293344: JDK-8242181 broke stack printing for non-attached threads

Reviewed-by: chagedorn, mdoerr

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

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

From duke at openjdk.org  Tue Sep  6 08:54:46 2022
From: duke at openjdk.org (xpbob)
Date: Tue, 6 Sep 2022 08:54:46 GMT
Subject: RFR: 8293340: [cleanup] Remove unused _code in
 TemplateInterpreterGenerator [v2]
In-Reply-To: <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
References: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
 <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
Message-ID: <phof__m3ifh5omCxEBr8p6-hKVqpjnoJD6P5qEn-3ZE=.334cadb0-638f-454c-aa20-4ff94d98768c@github.com>

On Sat, 3 Sep 2022 15:24:30 GMT, xpbob <duke at openjdk.org> wrote:

>> Hi all,
>> The _code arg in TemplateInterpreterGenerator is unused 
>> Remove `_code`
>> Thanks.
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add zeroInterpreter

Is it trivial? Or do I need a second review?

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

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

From shade at openjdk.org  Tue Sep  6 09:24:40 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Sep 2022 09:24:40 GMT
Subject: RFR: 8293340: [cleanup] Remove unused _code in
 TemplateInterpreterGenerator [v2]
In-Reply-To: <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
References: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
 <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
Message-ID: <ERcICV_zN9t-4rUbpx54Lv_llNLKDf_Z0reuwga3LH0=.0e779b63-a62a-4a73-926c-09a47d5e4058@github.com>

On Sat, 3 Sep 2022 15:24:30 GMT, xpbob <duke at openjdk.org> wrote:

>> Hi all,
>> The _code arg in TemplateInterpreterGenerator is unused 
>> Remove `_code`
>> Thanks.
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add zeroInterpreter

This looks fine. I changed the JBS issue a little to match what is happening here and did some digging why this is possible now: [JDK-8243996](https://bugs.openjdk.org/browse/JDK-8243996) made this possible.

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

Marked as reviewed by shade (Reviewer).

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

From duke at openjdk.org  Tue Sep  6 09:37:41 2022
From: duke at openjdk.org (xpbob)
Date: Tue, 6 Sep 2022 09:37:41 GMT
Subject: RFR: 8293340: Remove unused _code in
 {Zero,Template}InterpreterGenerator [v2]
In-Reply-To: <nuI_XqD8MYzS_456c-AWYk4zs6sB6XK8F0QHjPHDOfA=.b170f906-12be-4f82-b742-c67d23bea820@github.com>
References: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
 <Z1PwgFIfZbabrma6XsthSBQs3S-IRZeqERRUm_8bOMs=.19bdaf7b-ec84-437f-ba4b-18abf3c4dc10@github.com>
 <nuI_XqD8MYzS_456c-AWYk4zs6sB6XK8F0QHjPHDOfA=.b170f906-12be-4f82-b742-c67d23bea820@github.com>
Message-ID: <wan2bUrbHO6h7oprhkgAapM_DbaozY7bCZhfL-9St6M=.d43b3c40-4449-400a-afd1-d16daff6149d@github.com>

On Mon, 5 Sep 2022 01:32:48 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add zeroInterpreter
>
> LGTM

@DamonFool @shipilev 
Thanks for review,I have updated the title

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

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

From duke at openjdk.org  Tue Sep  6 09:41:52 2022
From: duke at openjdk.org (xpbob)
Date: Tue, 6 Sep 2022 09:41:52 GMT
Subject: Integrated: 8293340: Remove unused _code in
 {Zero,Template}InterpreterGenerator
In-Reply-To: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
References: <If3c25sPvRi_x1HQImdM8Emr4I_kopV7FFoMi96FBtc=.7bea0a8b-c95b-4497-ad93-04eb2746f4d1@github.com>
Message-ID: <BGa-7i_7UwHz_Nte5CEzFnxspIOWxHgGWftU7oFNJuw=.b3c7ab69-4a1c-4415-8f1b-d12c84b5f402@github.com>

On Sat, 3 Sep 2022 14:55:40 GMT, xpbob <duke at openjdk.org> wrote:

> Hi all,
> The _code arg in TemplateInterpreterGenerator is unused 
> Remove `_code`
> Thanks.

This pull request has now been integrated.

Changeset: 272745b3
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/272745b374533b8ddec31df6ae88388049c19738
Stats:     10 lines in 8 files changed: 0 ins; 0 del; 10 mod

8293340: Remove unused _code in {Zero,Template}InterpreterGenerator

Reviewed-by: jiefu, shade

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

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

From coleenp at openjdk.org  Tue Sep  6 14:02:43 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 6 Sep 2022 14:02:43 GMT
Subject: RFR: 8291736: find_method_handle_intrinsic leaks Method* [v4]
In-Reply-To: <nJOCIGdD6TSz_RSgWXpupKT8D3U2KoZpNdl9hiDK4FA=.cadf61d6-8c7a-477a-b642-2cd1242856ac@github.com>
References: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
 <nJOCIGdD6TSz_RSgWXpupKT8D3U2KoZpNdl9hiDK4FA=.cadf61d6-8c7a-477a-b642-2cd1242856ac@github.com>
Message-ID: <Smu-BF2CKcH4dQeiG1Vu9IEN_usSG7WEZNyKNbzk6xY=.ef1ba79d-f347-4d5f-b030-3f02a097abc3@github.com>

On Thu, 1 Sep 2022 15:01:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> As part of the SymbolPropertyTable conversion, we noticed that threads could race to add the Method entry to the table, and the loser wasn't deleted.  This change locks the InvokeMethodTable_lock through the Method creation so that it's not leaked.  See bug for details, but this was performance tested with our general suite of performance tests to show no significant differences.
>> Also tested with tier1-3, and previously 4-7 with SymbolPropertyTable conversion patch.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Thanks David.

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

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

From coleenp at openjdk.org  Tue Sep  6 14:04:50 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 6 Sep 2022 14:04:50 GMT
Subject: Integrated: 8291736: find_method_handle_intrinsic leaks Method*
In-Reply-To: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
References: <5UJMgFiitggqmlOaaB_630fbzy8Q0ZSWlHjgPHTu95c=.55a2e581-0540-4633-bfc0-5cc7462cd737@github.com>
Message-ID: <oHLuS0H-ZIuRKpNY7UXhhKPrQ2HA2Uebht8JjaxJl6c=.9942975f-65ae-4b11-89f9-452ba2e84f48@github.com>

On Tue, 23 Aug 2022 15:29:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> As part of the SymbolPropertyTable conversion, we noticed that threads could race to add the Method entry to the table, and the loser wasn't deleted.  This change locks the InvokeMethodTable_lock through the Method creation so that it's not leaked.  See bug for details, but this was performance tested with our general suite of performance tests to show no significant differences.
> Also tested with tier1-3, and previously 4-7 with SymbolPropertyTable conversion patch.

This pull request has now been integrated.

Changeset: c05015bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c05015bc93916303ff1f16dec5d9391d2d773f41
Stats:     33 lines in 1 file changed: 5 ins; 6 del; 22 mod

8291736: find_method_handle_intrinsic leaks Method*

Reviewed-by: hseigel, iklam, dholmes

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

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

From stuefe at openjdk.org  Tue Sep  6 16:33:07 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Sep 2022 16:33:07 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>
Message-ID: <S2TTUez4phT3vOnE3yOHBc7jemgVQfWAEomr1AE97fc=.9feaebf0-cf43-43e1-8899-a91dc8e3fb40@github.com>

On Fri, 2 Sep 2022 22:35:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update according to feedbacks.

Hi Xin,

This is good, and goes into the right direction.

General remark:

Since you allocate the buffers up-front, you really don't have to handle allocation failures. Just consider: 

- In the vast majority of cases the user will not modify `AsyncLogBufferSize`, and if we fail to malloc 4 MB at VM start we have a much larger problem.
- And *if* the user specifies `AsyncLogBufferSize`, but with such an outrageously large buffer that it fails to allocate, it is also better to fail. Because the user had a good reason to specify `-Xlog:async`, and you don't want to quietly fall back to synchronous logging. Also, maybe the user made just a stupid argument mistake, then again, you don't want to quielty swallow that error.

If you remove the allocation failure handling, you can simplify quite a bit, e.g. also get rid of `Buffer::is_valid()`, `AsyncLogWriter::Buffer::~Buffer()`, etc.

More remarks inline.

Cheers, Thomas

src/hotspot/share/logging/logAsyncWriter.cpp line 75:

> 73:     p->set_message(dest);
> 74:     _pos += sz;
> 75:     return true;

That's pretty hacky... :-) And `set_message` only exists because you need to repair the message pointer here, right?

Proposal:

Make AsyncLogMessage self-contained and variable-sized by letting the message follow the header. Like this:


class AsyncLogMessage {
  LogFileStreamOutput* _output;
  const LogDecorations _decorations;
  const size_t _len; // optional, or could also be 32- maybe even 16 bit
public:
  size_t len_in_bytes() const { return align_up(sizeof(AsyncLogMessage) + _len); }
  const char* message() { return (const char*) (this + 1); }
};


Then give it a placement new() and place it inside the Buffer right away instead of creating it on the stack and then copying it to the buffer. Just an idea.

src/hotspot/share/logging/logAsyncWriter.hpp line 50:

> 48:     constexpr size_t size = align_up(sizeof(*this), sizeof(void*));
> 49:     return _message != nullptr ? align_up(size + strlen(_message) + 1, sizeof(void*)): size;
> 50:   }

See my proposal. I would cache the strlen of the message in the header as the last member. You can use a smaller type too (Idk if we ever print out more than 64K in one log line). Since the string does not have to be aligned, you can save some bytes that way.

src/hotspot/share/logging/logAsyncWriter.hpp line 115:

> 113:       size_t _curr;
> 114: 
> 115:       void* raw_ptr() const {

Why a raw pointer? Why not `AsyncLogMessage*`? Iterator should never *not* point to a valid `AsyncLogMessage*`, unless we are at the end of the buffer.

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

Changes requested by stuefe (Reviewer).

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

From stuefe at openjdk.org  Tue Sep  6 16:33:08 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Sep 2022 16:33:08 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <S2TTUez4phT3vOnE3yOHBc7jemgVQfWAEomr1AE97fc=.9feaebf0-cf43-43e1-8899-a91dc8e3fb40@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>
 <S2TTUez4phT3vOnE3yOHBc7jemgVQfWAEomr1AE97fc=.9feaebf0-cf43-43e1-8899-a91dc8e3fb40@github.com>
Message-ID: <1fnBHDK7Ssa5lGsQec1Z4DZVdIFStuZf_rBKxu1QnXc=.6347c2a5-7b59-4501-8d4b-815147a71a54@github.com>

On Tue, 6 Sep 2022 16:11:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update according to feedbacks.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 75:
> 
>> 73:     p->set_message(dest);
>> 74:     _pos += sz;
>> 75:     return true;
> 
> That's pretty hacky... :-) And `set_message` only exists because you need to repair the message pointer here, right?
> 
> Proposal:
> 
> Make AsyncLogMessage self-contained and variable-sized by letting the message follow the header. Like this:
> 
> 
> class AsyncLogMessage {
>   LogFileStreamOutput* _output;
>   const LogDecorations _decorations;
>   const size_t _len; // optional, or could also be 32- maybe even 16 bit
> public:
>   size_t len_in_bytes() const { return align_up(sizeof(AsyncLogMessage) + _len); }
>   const char* message() { return (const char*) (this + 1); }
> };
> 
> 
> Then give it a placement new() and place it inside the Buffer right away instead of creating it on the stack and then copying it to the buffer. Just an idea.

Update: I looked at AsyncLogMessage and you are almost at what I propose anyway since the in-buffer version of AsyncLogMessage already follows my proposed layout. And your `AsyncLogMessage::size()` is similar to what I propose too. 

But the way you do it, you have two versions, one where the message follows the header, one where it is wherever. This means that `AsyncLogMessage::size()` is wrong for at least half the time.

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

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

From iklam at openjdk.org  Tue Sep  6 22:25:58 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 6 Sep 2022 22:25:58 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v6]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <5g3lAw0GmcHBrzqLLwfaHHDBQ6rCs0hVxP9LCxMt7Po=.7ea2e6fe-c760-44d7-95d1-fd5f47ece88f@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @coleenp comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10110/files
  - new: https://git.openjdk.org/jdk/pull/10110/files/aa927043..7fbd115e

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

  Stats: 21 lines in 4 files changed: 2 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10110.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10110/head:pull/10110

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

From iklam at openjdk.org  Tue Sep  6 22:25:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 6 Sep 2022 22:25:59 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v5]
In-Reply-To: <a6GgZF022XfCcZ7QhglYb-1lJj0D1Ac8lbNgBgst1BU=.c10a4cf8-683c-41f6-ade5-441bc3fb77a1@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <qU6HWqIXh8I_Q-YweDxl01da4Fmc2vP40ayKcUo9yVs=.f756239b-03e7-414f-8e8a-47ebfe9ec09c@github.com>
 <hbeEMneS_uNQHVKoqzI9QcnDqLjMtzaAif_jTN7m6Io=.ef62b789-3a67-4ae2-88b2-cec836110540@github.com>
 <a6GgZF022XfCcZ7QhglYb-1lJj0D1Ac8lbNgBgst1BU=.c10a4cf8-683c-41f6-ade5-441bc3fb77a1@github.com>
Message-ID: <xYqYmjPXYs6GLQpzZIdZ3admRKW-9DmEYxrVBYfNkM0=.b61ed22e-9796-48d1-90ef-e7c1a5d99af4@github.com>

On Fri, 2 Sep 2022 19:12:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/cds/cds_globals.hpp line 78:
>> 
>>> 76:           "product builds. The \"archivedObjects\" static field "           \
>>> 77:           "of the specified class is stored in the CDS archive heap")       \
>>> 78:                                                                             \
>> 
>> "Not available in product builds" is redundant with the flag definition.
>
> How about "The static field named "archivedObjects" of the specified class is stored in the CDS archive heap.

Fixed

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

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

From iklam at openjdk.org  Tue Sep  6 22:26:00 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 6 Sep 2022 22:26:00 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v5]
In-Reply-To: <hbeEMneS_uNQHVKoqzI9QcnDqLjMtzaAif_jTN7m6Io=.ef62b789-3a67-4ae2-88b2-cec836110540@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <qU6HWqIXh8I_Q-YweDxl01da4Fmc2vP40ayKcUo9yVs=.f756239b-03e7-414f-8e8a-47ebfe9ec09c@github.com>
 <hbeEMneS_uNQHVKoqzI9QcnDqLjMtzaAif_jTN7m6Io=.ef62b789-3a67-4ae2-88b2-cec836110540@github.com>
Message-ID: <o1vIS3nvdVlQaf4RK3Xqx0nVUAXW4DX66ZzL2f1wjjM=.502837ab-5189-4768-a7a1-3562a7fb5612@github.com>

On Fri, 2 Sep 2022 19:20:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed minimal build
>
> src/hotspot/share/cds/heapShared.cpp line 1542:
> 
>> 1540:     }
>> 1541: 
>> 1542:     Klass* k = SystemDictionary::resolve_or_fail(klass_name, true, THREAD);
> 
> Is this all only needed for #ifndef PRODUCT ?? if so you can put a ResourceMark unconditionally here because it seems like one might be needed.

We actually do resource allocation even in product mode (in error reporting), so I added ResourceMark in all cases.

> src/hotspot/share/cds/heapShared.cpp line 1663:
> 
>> 1661:         // otherwise it must be in (B).
>> 1662:         for (int j = 0; j < name->utf8_length(); j++) {
>> 1663:           if (name->char_at(j) == '/') {
> 
> Can you use strchr instead?

`name->base()` is not guarantee to be zero-terminated so I can't use `strchr`. I could use `memchr`, but since this code is executed only in asserts, I decided to use a higher-level function, `Symbol::index_of_at`.

I fixed the comments for `Symbol::index_of_at` and renamed its parameters to be clear what this function actually does.

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

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

From manc at openjdk.org  Tue Sep  6 23:09:44 2022
From: manc at openjdk.org (Man Cao)
Date: Tue, 6 Sep 2022 23:09:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <KYwvds6_oqM3IZUT3loxLmWCq9j0o-Twr-SCohHgyck=.068c72ad-0648-4818-acd6-d30d16997175@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <w5hiYKuGEu_gYuyD0BbuEcxyqs6uog_gH7SGR8OXUbU=.9c4d5993-117d-4cef-83e1-7ef849a08feb@github.com>
 <KYwvds6_oqM3IZUT3loxLmWCq9j0o-Twr-SCohHgyck=.068c72ad-0648-4818-acd6-d30d16997175@github.com>
Message-ID: <x6xvOLNAnAkHTQ5csf1WME9fHBhfmxLleFOe6LhkL6w=.76eff687-4fb0-4033-8250-2c1ed260b3f1@github.com>

On Tue, 23 Aug 2022 20:05:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> @caoman I'm interested in what your launcher does, or is, since I have almost never encountered signal chaining in the field. Would you mind sharing what product the launcher belongs to, and why you enable signal chaining?
>
>> @tstuefe Our launcher is equipped with almost all our Java applications. It basically does what bin/java does, but with several additional features. One main motivation to have our own launcher, is to static link all user-defined JNI dependency libraries with the launcher, so the applications do not need to use `System.loadLibrary()` to load `.so` files dynamically. Using static linking instead of dynamically loading `.so` files is core characteristic of our deployment environment for almost all languages (C, C++, Java, Python, Go). @jianglizhou is actually working on a project that also statically links HotSpot (`libjvm.so` and other `.so` files) with the our launcher as well.
> 
> That is interesting. Do you link statically to improve startup speed, or for some other reason?

@tstuefe Any feedback? I'd like to get this submitted soon to unblock our internal use cases relying on SIGQUIT and jcmd.

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

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

From iklam at openjdk.org  Tue Sep  6 23:26:39 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 6 Sep 2022 23:26:39 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v7]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into 8293182-improve-archive-heap-testing
 - @coleenp comments
 - fixed minimal build
 - Use help message suggedted by @calvinccheung
 - clarified assert message
 - @calvinccheung comments
 - fixed build (gcc spurious warning)
 - 8293182: Improve testing of CDS archive heap

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

Changes: https://git.openjdk.org/jdk/pull/10110/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10110&range=06
  Stats: 602 lines in 11 files changed: 521 ins; 32 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/10110.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10110/head:pull/10110

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

From stuefe at openjdk.org  Wed Sep  7 04:30:44 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Sep 2022 04:30:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <1a5ZnCQojLoOeJFdc-1moTNxDBlTgaxc_baH-b8yp2s=.5370ec7f-7bcc-449a-a27e-70156d60fae8@github.com>

On Sat, 20 Aug 2022 22:43:03 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

Sorry, missed this one. I'll take a look later today.

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

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

From stuefe at openjdk.org  Wed Sep  7 05:50:42 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Sep 2022 05:50:42 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <x6xvOLNAnAkHTQ5csf1WME9fHBhfmxLleFOe6LhkL6w=.76eff687-4fb0-4033-8250-2c1ed260b3f1@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <w5hiYKuGEu_gYuyD0BbuEcxyqs6uog_gH7SGR8OXUbU=.9c4d5993-117d-4cef-83e1-7ef849a08feb@github.com>
 <KYwvds6_oqM3IZUT3loxLmWCq9j0o-Twr-SCohHgyck=.068c72ad-0648-4818-acd6-d30d16997175@github.com>
 <x6xvOLNAnAkHTQ5csf1WME9fHBhfmxLleFOe6LhkL6w=.76eff687-4fb0-4033-8250-2c1ed260b3f1@github.com>
Message-ID: <PDZXcTnvLANHEMN83NcankZ02XjIwkhJinrKR2DADQc=.2733f0b6-db9c-4467-b1d2-6f442bd4c79a@github.com>

On Tue, 6 Sep 2022 23:07:39 GMT, Man Cao <manc at openjdk.org> wrote:

>>> @tstuefe Our launcher is equipped with almost all our Java applications. It basically does what bin/java does, but with several additional features. One main motivation to have our own launcher, is to static link all user-defined JNI dependency libraries with the launcher, so the applications do not need to use `System.loadLibrary()` to load `.so` files dynamically. Using static linking instead of dynamically loading `.so` files is core characteristic of our deployment environment for almost all languages (C, C++, Java, Python, Go). @jianglizhou is actually working on a project that also statically links HotSpot (`libjvm.so` and other `.so` files) with the our launcher as well.
>> 
>> That is interesting. Do you link statically to improve startup speed, or for some other reason?
>
> @tstuefe Any feedback? I'd like to get this submitted soon to unblock our internal use cases relying on SIGQUIT and jcmd.

@caoman While looking at this, I think I found an unrelated bug in libjsig. https://bugs.openjdk.org/browse/JDK-8293466 Could you eyeball it and tell me if my assumption is correct?

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

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

From manc at openjdk.org  Wed Sep  7 06:56:41 2022
From: manc at openjdk.org (Man Cao)
Date: Wed, 7 Sep 2022 06:56:41 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>

On Sat, 20 Aug 2022 22:43:03 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

Thanks for filing the other bug. Responded in that bug.

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

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

From duke at openjdk.org  Wed Sep  7 08:45:13 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 7 Sep 2022 08:45:13 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if manually
 mounted cpusets exist
Message-ID: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>

Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

Commit messages:
 - Fix crash of duplicate cg controller mountpoint

Changes: https://git.openjdk.org/jdk/pull/10193/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293472
  Stats: 89 lines in 3 files changed: 61 ins; 18 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10193/head:pull/10193

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

From duke at openjdk.org  Wed Sep  7 08:49:41 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 7 Sep 2022 08:49:41 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if
 manually mounted cpusets exist [v2]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <cYX0oaGW0eoVFa43fTJKgk3uqJzTsuJEiiMaLkpsB1Y=.ed270dd4-301b-4d67-a3ec-687127bbc944@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Explicit use name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/eb9c58b0..f989ad13

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

  Stats: 12 lines in 2 files changed: 4 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10193/head:pull/10193

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

From duke at openjdk.org  Wed Sep  7 09:01:40 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 7 Sep 2022 09:01:40 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if
 manually mounted cpusets exist [v3]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <BPgRxxB6v-FNsOJ1V0r14CKTir2uHSUNs0mtMSD-Elo=.5cca3b0b-69d3-4803-ac70-9bcc21958ec8@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/f989ad13..87306283

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

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

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

From duke at openjdk.org  Wed Sep  7 09:15:02 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 7 Sep 2022 09:15:02 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v5]
In-Reply-To: <Bb5HWPlCZG6yJEbX3sa0MReCmBdZtYGnyh6vcQ39zSU=.9be9fc24-433a-4070-bcd9-16542168e5d2@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
 <zhmKyAlUo5gpadIIxuOgaa3nszIKDtmfsuwd0sJTd4A=.85d1ff75-1554-420b-ba99-4f6ebd1847e6@github.com>
 <Bb5HWPlCZG6yJEbX3sa0MReCmBdZtYGnyh6vcQ39zSU=.9be9fc24-433a-4070-bcd9-16542168e5d2@github.com>
Message-ID: <VRpa6-opEssOIzap8PejKkq4H_f9ByVchcsCHyUNyqQ=.3c1f67aa-4a6d-49bd-ad39-3f04628e7671@github.com>

On Tue, 30 Aug 2022 00:13:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL.

Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this.

Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets.

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

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

From duke at openjdk.org  Wed Sep  7 09:16:52 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 7 Sep 2022 09:16:52 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if
 manually mounted cg controller exist [v4]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/87306283..3eed0907

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

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

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

From sgehwolf at openjdk.org  Wed Sep  7 09:59:44 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Sep 2022 09:59:44 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if
 manually mounted cg controller exist [v4]
In-Reply-To: <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>
Message-ID: <2vh0_4aTFj6ajk_oN-E5QQ0L-03v78QaGRP-PgEEg08=.1c18ddba-110e-49b1-99c0-877499160552@github.com>

On Wed, 7 Sep 2022 09:16:52 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Looks mostly good. https://bugs.openjdk.org/browse/JDK-8270087 seems to be an early sighting of this. It mentions a reproducer, manually mount `/sys/fs/cgroup` from the host into the container. Please write a container test asserting that no warnings get produced. Perhaps use `test/hotspot/jtreg/containers/docker/DockerBasicTest.java` and write a new test method `javaVersionWithCgMounts` or some such, which verifies no warning shows up on stdout.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 136:

> 134:     if (strstr(cg_infos[controller]._mount_path, "/sys/fs/cgroup") != cg_infos[controller]._mount_path) {
> 135:       log_warning(os, container)("Duplicate %s controllers detected. Picking %s, skipping %s.",
> 136:                                  name, mount_path, cg_infos[controller]._mount_path);

Please demote this to `log_debug` over a `log_warning`.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 141:

> 139:     } else {
> 140:       log_warning(os, container)("Duplicate %s controllers detected. Picking %s, skipping %s.",
> 141:                                  name, cg_infos[controller]._mount_path, mount_path);

Please demote this to `log_debug` over `log_warning`.

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

Changes requested by sgehwolf (Reviewer).

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

From sgehwolf at openjdk.org  Wed Sep  7 12:39:40 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Sep 2022 12:39:40 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if
 manually mounted cg controller exist [v4]
In-Reply-To: <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>
Message-ID: <go98QfWWWUkL5uXfkuFCaqLnmxbjyNZAav9nXtrM4Ug=.d7381173-04ee-42ce-8f10-98719fe438a8@github.com>

On Wed, 7 Sep 2022 09:16:52 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

My testing on cgv2 and cgv1 indicates that we might have a container resource limit detection problem depending on the order of `mountinfo` entries are observed at runtime. Please add memory and cpu limit container detection tests which do `-v /sys/fs/cgroup:/cgroups-in:ro` as a volume mount in addition. Thanks!

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

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

From stuefe at openjdk.org  Wed Sep  7 14:08:40 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Sep 2022 14:08:40 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
Message-ID: <xeMSHmLU0w4ijomOugSdoEd3Q4Kd8UjpIdTBhZyei-k=.345e6dfb-572c-4396-b846-b2c6de62f4fb@github.com>

On Wed, 7 Sep 2022 06:53:12 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Thanks for filing the other bug. Responded in that bug.

Looking at this, this gets more and more interesting. One thing, libjsig does nothing to prevent user code from changing thread/process sigmask. @caoman has that never been a problem at Google?

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

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

From stuefe at openjdk.org  Wed Sep  7 15:11:44 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Sep 2022 15:11:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <wCQhXc_5AHRsrTzAep9--mgzOlqDtj6__vNX02fSaPQ=.57f74464-3555-4f50-83d7-ff36989da22b@github.com>

On Sat, 20 Aug 2022 22:43:03 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

Found another minor one: https://bugs.openjdk.org/browse/JDK-8293494.

I'm looking at the change now, though.

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

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

From dcubed at openjdk.org  Wed Sep  7 15:24:50 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 15:24:50 GMT
Subject: RFR: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
Message-ID: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>

A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.

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

Commit messages:
 - 8293496: ProblemList runtime/os/TestTracePageSizes.java on linux-x64

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

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

From alanb at openjdk.org  Wed Sep  7 15:24:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 15:24:51 GMT
Subject: RFR: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
Message-ID: <beTPIbLD3BwYfy00hsfG1hKn3yg4fyKRMa4LIrsG5R0=.21e9bfff-effc-41f4-9969-9619ca9a2b06@github.com>

On Wed, 7 Sep 2022 15:18:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.

Marked as reviewed by alanb (Reviewer).

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

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

From azvegint at openjdk.org  Wed Sep  7 15:24:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Sep 2022 15:24:51 GMT
Subject: RFR: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
Message-ID: <CZ6Nl1MrGirVcBczT1r0QTXFJM3jrp0AAiT3zAzI3Nk=.0604afde-49df-4b1d-89a8-436c17fa807c@github.com>

On Wed, 7 Sep 2022 15:18:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.

Marked as reviewed by azvegint (Reviewer).

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

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

From dcubed at openjdk.org  Wed Sep  7 15:24:52 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 15:24:52 GMT
Subject: RFR: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <beTPIbLD3BwYfy00hsfG1hKn3yg4fyKRMa4LIrsG5R0=.21e9bfff-effc-41f4-9969-9619ca9a2b06@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
 <beTPIbLD3BwYfy00hsfG1hKn3yg4fyKRMa4LIrsG5R0=.21e9bfff-effc-41f4-9969-9619ca9a2b06@github.com>
Message-ID: <L2wle1IyClVfey_P5YaVfEaC9kCOovIWg83OvkNMQOk=.407ff141-e2dd-44ea-bc84-d18f7dfe1718@github.com>

On Wed, 7 Sep 2022 15:19:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman - Thanks for the lightning fast review!

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

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

From dcubed at openjdk.org  Wed Sep  7 15:29:11 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 15:29:11 GMT
Subject: Integrated: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
Message-ID: <hd4Rv3iIYNGYPGYb0eTm52MQhQiWXkKeWMrmtnolWQk=.d565cda5-5871-4eaf-be32-636889adef9c@github.com>

On Wed, 7 Sep 2022 15:18:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.

This pull request has now been integrated.

Changeset: d36abbe8
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d36abbe8dab3618a08a8a87f53411ed92823d471
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8293496: ProblemList runtime/os/TestTracePageSizes.java on linux-x64

Reviewed-by: alanb, azvegint

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

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

From stuefe at openjdk.org  Wed Sep  7 16:53:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Sep 2022 16:53:45 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
Message-ID: <qXt5OL5Gif6tMvzj-9yJdjFYTrrjz9SMYQ6y-XpSU_s=.8fd758c8-d2be-49ee-84a9-178db9bd55eb@github.com>

On Wed, 7 Sep 2022 06:53:12 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Thanks for filing the other bug. Responded in that bug.

Hi @caoman, @dholmes-ora, @navyxliu,

I wonder if it has to be that complicated.

The problems (both https://bugs.openjdk.org/browse/JDK-8279124 and https://bugs.openjdk.org/browse/JDK-8292695) are caused by SIGQUIT being in a weird space - it is a VM signal, really, but gets handled by the signal dispatcher thread. The signal dispatcher thread is started long after the "real" hotspot handlers are installed. And after the dispatcher thread starts, only then we install the SIGQUIT handler. At that point the libjsig is already in "surveillance" mode where it intercepts stuff.

But there is nothing that prevents us from moving the SIGQUIT handler installation up in time to the hotspot signal handler initialization. Nobody says the SIGQUIT handler has to be installed *after* the signal dispatcher thread started.

Signal dispatcher thread and handler are only loosely coupled via `os::signal_notify()`. If the VM receives SIGQUIT in the time window after the SIGQUIT handler is installed but before the signal dispatcher thread is started, handler will just "ring the bell", but thats fine. The notifications would stack, and once the dispatcher thread runs, it will process all these SIGQUIT signals in a delayed fashion.


To test my theory, I built: https://github.com/openjdk/jdk/compare/master...tstuefe:jdk:test-move-sigquit-init-up-in-time .

This moves signal handler installation up in time. It also optionally adds a delay between hotspot signal handler installation and dispatcher thread startup. 

And this just works as expected: if we send SIGQUIT to the VM, we get thread dumps. Before dispatcher thread start, these SIGQUITs are "stored", and executed all once dispatcher thread starts (whether or not one wants that is a different question, but easily to modify). And SIGQUITs after dispatcher startup work fine as expected.

As expected this works with or without libjsig, so it solves JDK-8292695. It also closes the initial time window and therefore does not regress JDK-8279124. And it is a lot simpler to argue about, especially with libjsig present. Now SIGQUIT is handled like any other ordinary hotspot signal.

(and I wonder whether we could handle the shutdown signals the same way, but have not tested).

What do you think?

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

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

From stuefe at openjdk.org  Wed Sep  7 17:03:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Sep 2022 17:03:25 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal block
 state
Message-ID: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>

I needed this recently. We print out the signal block mask, which is fine, but more interesting would be the existing block state at the point of the crash/assertion.

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

Commit messages:
 - Merge branch 'master' into JDK-8293493-print-signal-block-state-in-sighandler-printout
 - dont scream so much
 - JDK-8293493-print-signal-block-state-in-sighandler-printout

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

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

From coleenp at openjdk.org  Wed Sep  7 17:53:42 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 Sep 2022 17:53:42 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v7]
In-Reply-To: <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
Message-ID: <NdEk8eXiBIVbDmZ0FGFFsxxWKLKRF-EQkFfETFgCyYg=.ebbf2d59-21e9-414d-bcab-f514a051afb1@github.com>

On Tue, 6 Sep 2022 23:26:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
>> 
>> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
>> 
>> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
>> 
>> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
>> 
>> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
>> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into 8293182-improve-archive-heap-testing
>  - @coleenp comments
>  - fixed minimal build
>  - Use help message suggedted by @calvinccheung
>  - clarified assert message
>  - @calvinccheung comments
>  - fixed build (gcc spurious warning)
>  - 8293182: Improve testing of CDS archive heap

Ok.

src/hotspot/share/cds/heapShared.hpp line 298:

> 296: 
> 297:   static void resolve_classes_for_subgraphs(ArchivableStaticFieldInfo fields[],
> 298:                                             JavaThread* THREAD);

Should this be TRAPS or JavaThread* current?

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

Marked as reviewed by coleenp (Reviewer).

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

From dcubed at openjdk.org  Wed Sep  7 18:33:48 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 18:33:48 GMT
Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java
 - launch timeout
In-Reply-To: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
Message-ID: <5xzd8QAs_3F876p7P8wYCFRmcN1_3PHE5imqj0u4df0=.a97d2a13-3edd-4b61-81ad-1e552cb15601@github.com>

On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
> Also cleaned up an incorrect comment.

Used the latest patch in my jdk-20+13 stress runs on linux-x64 and
macosx-aarch64 and there were no failures.

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

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

From dcubed at openjdk.org  Wed Sep  7 18:33:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 18:33:49 GMT
Subject: Integrated: 8207166:
 jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout
In-Reply-To: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
Message-ID: <BZmpT2mi_bCB38NZ_6bUMHYNA3dWYn7p2fopPheXPps=.124c929b-d4af-4574-aec2-a1a520946d7e@github.com>

On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
> Also cleaned up an incorrect comment.

This pull request has now been integrated.

Changeset: 02dce24b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02dce24b59ab53f00309a71ee94f45067c880b5c
Stats:     9 lines in 2 files changed: 3 ins; 0 del; 6 mod

8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout

Reviewed-by: vromero

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

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

From xliu at openjdk.org  Wed Sep  7 19:08:45 2022
From: xliu at openjdk.org (Xin Liu)
Date: Wed, 7 Sep 2022 19:08:45 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <1fnBHDK7Ssa5lGsQec1Z4DZVdIFStuZf_rBKxu1QnXc=.6347c2a5-7b59-4501-8d4b-815147a71a54@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>
 <S2TTUez4phT3vOnE3yOHBc7jemgVQfWAEomr1AE97fc=.9feaebf0-cf43-43e1-8899-a91dc8e3fb40@github.com>
 <1fnBHDK7Ssa5lGsQec1Z4DZVdIFStuZf_rBKxu1QnXc=.6347c2a5-7b59-4501-8d4b-815147a71a54@github.com>
Message-ID: <NoMkJlTYkhJUvD3Akrvj2F3c3vi3CSZKx9-NWmgxDJQ=.046a1aef-8614-4f8c-b1b9-8f726a8a4bd7@github.com>

On Tue, 6 Sep 2022 16:23:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 75:
>> 
>>> 73:     p->set_message(dest);
>>> 74:     _pos += sz;
>>> 75:     return true;
>> 
>> That's pretty hacky... :-) And `set_message` only exists because you need to repair the message pointer here, right?
>> 
>> Proposal:
>> 
>> Make AsyncLogMessage self-contained and variable-sized by letting the message follow the header. Like this:
>> 
>> 
>> class AsyncLogMessage {
>>   LogFileStreamOutput* _output;
>>   const LogDecorations _decorations;
>>   const size_t _len; // optional, or could also be 32- maybe even 16 bit
>> public:
>>   size_t len_in_bytes() const { return align_up(sizeof(AsyncLogMessage) + _len); }
>>   const char* message() { return (const char*) (this + 1); }
>> };
>> 
>> 
>> Then give it a placement new() and place it inside the Buffer right away instead of creating it on the stack and then copying it to the buffer. Just an idea.
>
> Update: I looked at AsyncLogMessage and you are almost at what I propose anyway since the in-buffer version of AsyncLogMessage already follows my proposed layout. And your `AsyncLogMessage::size()` is similar to what I propose too. 
> 
> But the way you do it, you have two versions, one where the message follows the header, one where it is wherever. This means that `AsyncLogMessage::size()` is wrong for at least half the time.

I prefer trailing 0 because `AsyncLogMessage::message()` can be treated as a valid c-string and pass to LogFileStreamOutput. If so, `len` is optional indeed. The benefit of `len` is that we can iterate buffer faster. We will have O(1) time-complexity instead of O(len) in `Buffer::Iterator::next() `

I see your point. It's more elegant to use `implicit` message. The reason I need to handle `msg= nullptr` is that flushing Token uses it. I can replace it with "" instead.

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

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

From dcubed at openjdk.org  Wed Sep  7 19:45:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 19:45:49 GMT
Subject: RFR: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <CZ6Nl1MrGirVcBczT1r0QTXFJM3jrp0AAiT3zAzI3Nk=.0604afde-49df-4b1d-89a8-436c17fa807c@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
 <CZ6Nl1MrGirVcBczT1r0QTXFJM3jrp0AAiT3zAzI3Nk=.0604afde-49df-4b1d-89a8-436c17fa807c@github.com>
Message-ID: <0C8JzZ2dqps9gGcY9EgMiGavNgSba8XYCwrQur1DNBI=.62149552-cba6-4f6c-b3e2-5044393adf72@github.com>

On Wed, 7 Sep 2022 15:20:54 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for your review also. (Just caught up on the email thread).

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

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

From ccheung at openjdk.org  Wed Sep  7 19:48:42 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 7 Sep 2022 19:48:42 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v7]
In-Reply-To: <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
Message-ID: <OgQVzT0lrEczxqWLAQMxd2C1Ke03Wev2hQe8Ko3LCwA=.19958bfb-e1fe-4ced-bbf9-59f8f0c62d0a@github.com>

On Tue, 6 Sep 2022 23:26:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
>> 
>> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
>> 
>> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
>> 
>> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
>> 
>> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
>> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into 8293182-improve-archive-heap-testing
>  - @coleenp comments
>  - fixed minimal build
>  - Use help message suggedted by @calvinccheung
>  - clarified assert message
>  - @calvinccheung comments
>  - fixed build (gcc spurious warning)
>  - 8293182: Improve testing of CDS archive heap

Updates look good. Just one nit.

test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg/ClassInPackage.java line 1:

> 1: package pkg;

Does this simple test class require a copyright header?

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

Marked as reviewed by ccheung (Reviewer).

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

From manc at openjdk.org  Wed Sep  7 19:49:48 2022
From: manc at openjdk.org (Man Cao)
Date: Wed, 7 Sep 2022 19:49:48 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
Message-ID: <qbR4TQEkPZ_qcQYBHMkqfealu4fq3Pq3oTwSZe6kdd0=.5e4d3b9a-0d33-40b2-beb0-7fdd37e70021@github.com>

On Wed, 7 Sep 2022 06:53:12 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Thanks for filing the other bug. Responded in that bug.

> One thing, libjsig does nothing to prevent user code from changing thread/process sigmask. @caoman has that never been a problem at Google?

We don't actually use libjsig directly. Our launcher reimplemented signal chaining support using the same JVM_begin_signal_setting/JVM_end_signal_setting/JVM_get_signal_action interface.

Our launcher's implementation has calls to pthread_sigmask, but the goal seems to make the overridden sigaction() async-signal-safe. It doesn't prevent user code from changing thread/process sigmask either. However, I haven't heard of issues with user code changing sigmask.

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

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

From manc at openjdk.org  Wed Sep  7 20:13:44 2022
From: manc at openjdk.org (Man Cao)
Date: Wed, 7 Sep 2022 20:13:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <qXt5OL5Gif6tMvzj-9yJdjFYTrrjz9SMYQ6y-XpSU_s=.8fd758c8-d2be-49ee-84a9-178db9bd55eb@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
 <qXt5OL5Gif6tMvzj-9yJdjFYTrrjz9SMYQ6y-XpSU_s=.8fd758c8-d2be-49ee-84a9-178db9bd55eb@github.com>
Message-ID: <cp8-hKbtbpMGkwy-p1f3e28RajWXgbqeDagWW-9tznw=.539e1521-9ee6-4f3b-a303-40607af7f6a3@github.com>

On Wed, 7 Sep 2022 16:51:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> But there is nothing that prevents us from moving the SIGQUIT handler installation up in time to the hotspot signal handler initialization. Nobody says the SIGQUIT handler has to be installed after the signal dispatcher thread started.

Thank you for the great idea and experiment! Let me try this approach and rerun the tests.

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

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

From dcubed at openjdk.org  Wed Sep  7 20:39:43 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 20:39:43 GMT
Subject: RFR: 8293508: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
Message-ID: <P4miiD9YfpVmEXUcuWoErtkLxez2U-96ARHuceN5_ug=.3c219d4c-0c50-4058-86ed-f981160fdd03@github.com>

A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
on macosx-all and windows-x64.

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

Commit messages:
 - 8293508: ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64

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

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

From bpb at openjdk.org  Wed Sep  7 20:39:43 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Sep 2022 20:39:43 GMT
Subject: RFR: 8293508: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
In-Reply-To: <P4miiD9YfpVmEXUcuWoErtkLxez2U-96ARHuceN5_ug=.3c219d4c-0c50-4058-86ed-f981160fdd03@github.com>
References: <P4miiD9YfpVmEXUcuWoErtkLxez2U-96ARHuceN5_ug=.3c219d4c-0c50-4058-86ed-f981160fdd03@github.com>
Message-ID: <FiZxijL8wp9nKoiSE5ApPK3jIqA6H36CLNwxcOcq3gc=.1c5a2eee-6cab-4294-8b95-99b4ef6d0b8e@github.com>

On Wed, 7 Sep 2022 20:25:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
> on macosx-all and windows-x64.

Marked as reviewed by bpb (Reviewer).

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

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

From dcubed at openjdk.org  Wed Sep  7 20:39:45 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 20:39:45 GMT
Subject: RFR: 8293508: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
In-Reply-To: <FiZxijL8wp9nKoiSE5ApPK3jIqA6H36CLNwxcOcq3gc=.1c5a2eee-6cab-4294-8b95-99b4ef6d0b8e@github.com>
References: <P4miiD9YfpVmEXUcuWoErtkLxez2U-96ARHuceN5_ug=.3c219d4c-0c50-4058-86ed-f981160fdd03@github.com>
 <FiZxijL8wp9nKoiSE5ApPK3jIqA6H36CLNwxcOcq3gc=.1c5a2eee-6cab-4294-8b95-99b4ef6d0b8e@github.com>
Message-ID: <cP4HO3tw3qYNwXkcF8wbuNQ4UubH1Syp4c_KWxtc6K8=.f75fe6a4-63fe-4306-b215-81ac970dd976@github.com>

On Wed, 7 Sep 2022 20:26:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
>> on macosx-all and windows-x64.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the lightning fast review!

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

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

From dcubed at openjdk.org  Wed Sep  7 20:52:18 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 20:52:18 GMT
Subject: Integrated: 8293508: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
In-Reply-To: <P4miiD9YfpVmEXUcuWoErtkLxez2U-96ARHuceN5_ug=.3c219d4c-0c50-4058-86ed-f981160fdd03@github.com>
References: <P4miiD9YfpVmEXUcuWoErtkLxez2U-96ARHuceN5_ug=.3c219d4c-0c50-4058-86ed-f981160fdd03@github.com>
Message-ID: <0xqLDOw9_UjcEo6Osb31h9HtBTiw-ZrH566PB0remXE=.76bf57c0-54b7-4420-834a-2729a28d6a97@github.com>

On Wed, 7 Sep 2022 20:25:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64
> on macosx-all and windows-x64.

This pull request has now been integrated.

Changeset: 1080c4e4
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1080c4e4aeb88e68f5ccb6e1909a084a5b6fa0d3
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8293508: ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64

Reviewed-by: bpb

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

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

From dcubed at openjdk.org  Wed Sep  7 21:31:21 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 21:31:21 GMT
Subject: RFR: 8293514: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms
Message-ID: <yvjO4Lr0DooB1_Kf2rdxnk-n_X742ChTXfjSS1qhb0w=.6704d385-b529-43d4-a2d2-58c2cbe44d29@github.com>

A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms.

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

Commit messages:
 - 8293514: ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms

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

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

From kbarrett at openjdk.org  Wed Sep  7 21:31:21 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Sep 2022 21:31:21 GMT
Subject: RFR: 8293514: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms
In-Reply-To: <yvjO4Lr0DooB1_Kf2rdxnk-n_X742ChTXfjSS1qhb0w=.6704d385-b529-43d4-a2d2-58c2cbe44d29@github.com>
References: <yvjO4Lr0DooB1_Kf2rdxnk-n_X742ChTXfjSS1qhb0w=.6704d385-b529-43d4-a2d2-58c2cbe44d29@github.com>
Message-ID: <V-CgFUNU2y2jKbVAZgMlI_FK-gUN3mCx2tHbfXowjbw=.e4b12643-e0d7-4355-beb3-9b7d3b2608c6@github.com>

On Wed, 7 Sep 2022 21:23:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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

From dcubed at openjdk.org  Wed Sep  7 21:31:21 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 21:31:21 GMT
Subject: RFR: 8293514: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms
In-Reply-To: <V-CgFUNU2y2jKbVAZgMlI_FK-gUN3mCx2tHbfXowjbw=.e4b12643-e0d7-4355-beb3-9b7d3b2608c6@github.com>
References: <yvjO4Lr0DooB1_Kf2rdxnk-n_X742ChTXfjSS1qhb0w=.6704d385-b529-43d4-a2d2-58c2cbe44d29@github.com>
 <V-CgFUNU2y2jKbVAZgMlI_FK-gUN3mCx2tHbfXowjbw=.e4b12643-e0d7-4355-beb3-9b7d3b2608c6@github.com>
Message-ID: <c7cNJKtdx-o1QdLNPvdv6P1jAc8BIOc2p61Ghvuv3z0=.6e21a9e7-106c-4ddb-b390-2999ac798311@github.com>

On Wed, 7 Sep 2022 21:25:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms.
>
> Looks good.

@kimbarrett - Thanks for the lightning fast review!

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

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

From iklam at openjdk.org  Wed Sep  7 21:32:08 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 Sep 2022 21:32:08 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v8]
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <pKBX758O3o1jWTLCG6OOk2-GchDjYBaRC0fKsP52xi4=.f06e004f-eade-4fe4-b815-24a291bc227c@github.com>

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  added copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10110/files
  - new: https://git.openjdk.org/jdk/pull/10110/files/d5e8639f..c2f0e8d3

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

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

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

From iklam at openjdk.org  Wed Sep  7 21:33:37 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 Sep 2022 21:33:37 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v7]
In-Reply-To: <NdEk8eXiBIVbDmZ0FGFFsxxWKLKRF-EQkFfETFgCyYg=.ebbf2d59-21e9-414d-bcab-f514a051afb1@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
 <NdEk8eXiBIVbDmZ0FGFFsxxWKLKRF-EQkFfETFgCyYg=.ebbf2d59-21e9-414d-bcab-f514a051afb1@github.com>
Message-ID: <mfvZ6c1UDlwBaMtYcTFumBmR_xRN-95pN-yYIM1CgqI=.f9f1882a-3383-4e7c-80b7-7a3969338e3c@github.com>

On Wed, 7 Sep 2022 17:49:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8293182-improve-archive-heap-testing
>>  - @coleenp comments
>>  - fixed minimal build
>>  - Use help message suggedted by @calvinccheung
>>  - clarified assert message
>>  - @calvinccheung comments
>>  - fixed build (gcc spurious warning)
>>  - 8293182: Improve testing of CDS archive heap
>
> src/hotspot/share/cds/heapShared.hpp line 298:
> 
>> 296: 
>> 297:   static void resolve_classes_for_subgraphs(ArchivableStaticFieldInfo fields[],
>> 298:                                             JavaThread* THREAD);
> 
> Should this be TRAPS or JavaThread* current?

It should be `JavaThread* current`. I'll try to fix that in a separate RFE: https://bugs.openjdk.org/browse/JDK-8293515

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

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

From iklam at openjdk.org  Wed Sep  7 21:33:39 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 Sep 2022 21:33:39 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v7]
In-Reply-To: <OgQVzT0lrEczxqWLAQMxd2C1Ke03Wev2hQe8Ko3LCwA=.19958bfb-e1fe-4ced-bbf9-59f8f0c62d0a@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
 <OgQVzT0lrEczxqWLAQMxd2C1Ke03Wev2hQe8Ko3LCwA=.19958bfb-e1fe-4ced-bbf9-59f8f0c62d0a@github.com>
Message-ID: <r1xBbbK8lCx2DJTwcTJsWMjaTMUJTDJH6s7At9Y_lH8=.f5038608-7d41-4f1c-9942-51ed9022d50f@github.com>

On Wed, 7 Sep 2022 19:44:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8293182-improve-archive-heap-testing
>>  - @coleenp comments
>>  - fixed minimal build
>>  - Use help message suggedted by @calvinccheung
>>  - clarified assert message
>>  - @calvinccheung comments
>>  - fixed build (gcc spurious warning)
>>  - 8293182: Improve testing of CDS archive heap
>
> test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg/ClassInPackage.java line 1:
> 
>> 1: package pkg;
> 
> Does this simple test class require a copyright header?

Fixed.

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

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

From dcubed at openjdk.org  Wed Sep  7 21:37:01 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 21:37:01 GMT
Subject: Integrated: 8293514: ProblemList
 gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms
In-Reply-To: <yvjO4Lr0DooB1_Kf2rdxnk-n_X742ChTXfjSS1qhb0w=.6704d385-b529-43d4-a2d2-58c2cbe44d29@github.com>
References: <yvjO4Lr0DooB1_Kf2rdxnk-n_X742ChTXfjSS1qhb0w=.6704d385-b529-43d4-a2d2-58c2cbe44d29@github.com>
Message-ID: <6wk_fCDbLFhWQzHx0m5knf99ENCz29ktmcvIhVrzqJ4=.e68f647a-c9a0-4f99-abe0-368bfaf94a8e@github.com>

On Wed, 7 Sep 2022 21:23:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms.

This pull request has now been integrated.

Changeset: 8a489658
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a489658ab51460fa8190f20c7e592b1997d48d9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8293514: ProblemList gc/metaspace/TestMetaspacePerfCounters.java#Epsilon-64 on all platforms

Reviewed-by: kbarrett

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

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

From dcubed at openjdk.org  Wed Sep  7 22:09:29 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 22:09:29 GMT
Subject: RFR: 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java
 in -Xcomp mode
Message-ID: <uZOVKk1ZxAnlq7yom09AtQMGLn-ILrI0D74QJIhNz6A=.326825d0-ef61-4e4d-94e5-9647111532f2@github.com>

Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:

[JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode

[JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode

[JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64

[JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java

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

Commit messages:
 - 8293518: ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java
 - 8293517: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
 - 8293516: ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode
 - 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode

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

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

From bpb at openjdk.org  Wed Sep  7 22:09:30 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Sep 2022 22:09:30 GMT
Subject: RFR: 8293512: ProblemList
 serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
In-Reply-To: <uZOVKk1ZxAnlq7yom09AtQMGLn-ILrI0D74QJIhNz6A=.326825d0-ef61-4e4d-94e5-9647111532f2@github.com>
References: <uZOVKk1ZxAnlq7yom09AtQMGLn-ILrI0D74QJIhNz6A=.326825d0-ef61-4e4d-94e5-9647111532f2@github.com>
Message-ID: <xblVGzj8AqSnpXM4SqlkwCgvUs94xj2THQ03QRUE8IA=.cdca4d4b-f35e-4309-ba1a-d5e34dd7bc69@github.com>

On Wed, 7 Sep 2022 21:53:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
> 
> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
> 
> [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode
> 
> [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
> 
> [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java

Marked as reviewed by bpb (Reviewer).

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

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

From iklam at openjdk.org  Wed Sep  7 23:06:11 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 Sep 2022 23:06:11 GMT
Subject: Integrated: 8293182: Improve testing of CDS archive heap
In-Reply-To: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
Message-ID: <IA1G3gQRsV_26i0WlMGQAI6TUBFeb7IJuZrri7kTkmU=.fc9e3e59-f4b5-439e-8f61-6ad2d154d3c1@github.com>

On Wed, 31 Aug 2022 22:52:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Currently, the CDS archive heap supports a fixed set of built-in classes, specified by hard-coded lists in heapShared.cpp:
> 
> https://github.com/openjdk/jdk/blob/372fc58e897d25713db0dfe289ed25c40d9a3985/src/hotspot/share/cds/heapShared.cpp#L104-L107
> 
> As we plan to improve the archive heap, it becomes critical to be able to write specific test cases for different scenarios.
> 
> For example, supporting LambdaForms in the CDS archive heap would require archiving enums of the type [sun.invoke.util.Wrapper](https://github.com/openjdk/jdk/blob/607612899678234c093dc644d3a40cb831c7e43b/src/java.base/share/classes/sun/invoke/util/Wrapper.java), which doesn't work yet (see [JDK-8293187](https://bugs.openjdk.org/browse/JDK-8293187)). This RFE makes it possible to develop support for sun.invoke.util.Wrapper separately, without implementing the full support of LambdaForms in a single colossal step.
> 
> - Added `-XX:ArchiveHeapTestClass` to inject extra classes into the archive heap. See the test case ArchiveHeapTestClass.java for examples. For paranoia, This flag is available only in debug builds.
> - I also tighten the requirement for the type of classes that can be stored into the archive heap. E.g., we no longer allow classes outside of the `java.base` module.

This pull request has now been integrated.

Changeset: f84386cf
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f84386cf6e96aef657aff7b57476639d55045cc4
Stats:     603 lines in 11 files changed: 520 ins; 32 del; 51 mod

8293182: Improve testing of CDS archive heap

Reviewed-by: ccheung, coleenp

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

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

From iklam at openjdk.org  Wed Sep  7 23:06:10 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 Sep 2022 23:06:10 GMT
Subject: RFR: 8293182: Improve testing of CDS archive heap [v7]
In-Reply-To: <OgQVzT0lrEczxqWLAQMxd2C1Ke03Wev2hQe8Ko3LCwA=.19958bfb-e1fe-4ced-bbf9-59f8f0c62d0a@github.com>
References: <ZYoryf_dc9VHQJTM480t_vsKMvDp-KyT19yHXADrvHs=.6009b31d-ecfb-4a58-83cf-2e96aa136cdd@github.com>
 <3aKFTj-rhkcwINwRatVYwH_T9YW033vr3dH_dGRo_XU=.c35e72b0-66ad-4198-b339-20d12ed17034@github.com>
 <OgQVzT0lrEczxqWLAQMxd2C1Ke03Wev2hQe8Ko3LCwA=.19958bfb-e1fe-4ced-bbf9-59f8f0c62d0a@github.com>
Message-ID: <ESXLM9t3hnfp3bD7VrBJ4IWs3W2nJP2Z9oBGI0OzXPg=.2dd9d640-b33e-44f7-bfa8-fe50dc8ad878@github.com>

On Wed, 7 Sep 2022 19:45:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8293182-improve-archive-heap-testing
>>  - @coleenp comments
>>  - fixed minimal build
>>  - Use help message suggedted by @calvinccheung
>>  - clarified assert message
>>  - @calvinccheung comments
>>  - fixed build (gcc spurious warning)
>>  - 8293182: Improve testing of CDS archive heap
>
> Updates look good. Just one nit.

Thanks @calvinccheung and @coleenp for the review.

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

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

From dcubed at openjdk.org  Wed Sep  7 23:09:43 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 23:09:43 GMT
Subject: RFR: 8293512: ProblemList
 serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
In-Reply-To: <xblVGzj8AqSnpXM4SqlkwCgvUs94xj2THQ03QRUE8IA=.cdca4d4b-f35e-4309-ba1a-d5e34dd7bc69@github.com>
References: <uZOVKk1ZxAnlq7yom09AtQMGLn-ILrI0D74QJIhNz6A=.326825d0-ef61-4e4d-94e5-9647111532f2@github.com>
 <xblVGzj8AqSnpXM4SqlkwCgvUs94xj2THQ03QRUE8IA=.cdca4d4b-f35e-4309-ba1a-d5e34dd7bc69@github.com>
Message-ID: <Ad30VWrerK_nuKFsPgPaZoKP8_CSVgrsQrZ_HsD1f6c=.c0ea1185-3531-432f-8719-2c152bdf09fb@github.com>

On Wed, 7 Sep 2022 22:03:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
>> 
>> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
>> 
>> [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode
>> 
>> [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
>> 
>> [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the review.

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

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

From dcubed at openjdk.org  Wed Sep  7 23:12:44 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 23:12:44 GMT
Subject: Integrated: 8293512: ProblemList
 serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
In-Reply-To: <uZOVKk1ZxAnlq7yom09AtQMGLn-ILrI0D74QJIhNz6A=.326825d0-ef61-4e4d-94e5-9647111532f2@github.com>
References: <uZOVKk1ZxAnlq7yom09AtQMGLn-ILrI0D74QJIhNz6A=.326825d0-ef61-4e4d-94e5-9647111532f2@github.com>
Message-ID: <P51iOh_V8yRIXTyGlmnxquIr-OETbV7fVnyQn0ZYtxo=.b0bf742b-061d-4a66-847e-2f312b71545d@github.com>

On Wed, 7 Sep 2022 21:53:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
> 
> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
> 
> [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode
> 
> [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
> 
> [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java

This pull request has now been integrated.

Changeset: 2d13f530
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d13f53017377128b7a8f1e3da9a09f7af92085a
Stats:     5 lines in 2 files changed: 5 ins; 0 del; 0 mod

8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
8293516: ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode
8293517: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
8293518: ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java

Reviewed-by: bpb

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

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

From xliu at openjdk.org  Thu Sep  8 00:18:38 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 8 Sep 2022 00:18:38 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v3]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <32Lf7PlV9PJTwP0dGJc1z3o2Vge33mVBxTCFXAvDdjQ=.4a30844b-3130-4bf7-9d79-cfdef7cb268d@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Use implicit c-str field for message().
  
  This saves a pointer(8-byte on LP64 machines) for each message.
  Resume default size of buffer to 2M because -Xlog:all=debug
  -Xlog:async doesn't drop any message.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/1950a63d..8c3efc16

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

  Stats: 143 lines in 3 files changed: 45 ins; 66 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10092.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10092/head:pull/10092

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

From xliu at openjdk.org  Thu Sep  8 00:36:40 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 8 Sep 2022 00:36:40 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <NoMkJlTYkhJUvD3Akrvj2F3c3vi3CSZKx9-NWmgxDJQ=.046a1aef-8614-4f8c-b1b9-8f726a8a4bd7@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>
 <S2TTUez4phT3vOnE3yOHBc7jemgVQfWAEomr1AE97fc=.9feaebf0-cf43-43e1-8899-a91dc8e3fb40@github.com>
 <1fnBHDK7Ssa5lGsQec1Z4DZVdIFStuZf_rBKxu1QnXc=.6347c2a5-7b59-4501-8d4b-815147a71a54@github.com>
 <NoMkJlTYkhJUvD3Akrvj2F3c3vi3CSZKx9-NWmgxDJQ=.046a1aef-8614-4f8c-b1b9-8f726a8a4bd7@github.com>
Message-ID: <PZ6mIJYPObwysQ4yk1UPF-7B1q-G8g1YZtZ0epWIk2E=.c08317ac-48e9-448b-921c-a371b5b24f26@github.com>

On Wed, 7 Sep 2022 19:04:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Update: I looked at AsyncLogMessage and you are almost at what I propose anyway since the in-buffer version of AsyncLogMessage already follows my proposed layout. And your `AsyncLogMessage::size()` is similar to what I propose too. 
>> 
>> But the way you do it, you have two versions, one where the message follows the header, one where it is wherever. This means that `AsyncLogMessage::size()` is wrong for at least half the time.
>
> I prefer trailing 0 because `AsyncLogMessage::message()` can be treated as a valid c-string and pass to LogFileStreamOutput. If so, `len` is optional indeed. The benefit of `len` is that we can iterate buffer faster. We will have O(1) time-complexity instead of O(len) in `Buffer::Iterator::next() `
> 
> I see your point. It's more elegant to use `implicit` message. The reason I need to handle `msg= nullptr` is that flushing Token uses it. I can replace it with "" instead.

I update to use in-place new for AsyncLogMessage objects. For safety, I change AsyncLogMessage to a nested class and rename it to 'Message'. It's private so it's not accessible by outside.

Previously, we had at least one extra copy of `LogDecorations`. Now it aligns with c-str message. We materialize them only in constructor. Because we have to support asynchronous execution, this is optimal.

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

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

From manc at openjdk.org  Thu Sep  8 02:41:56 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 02:41:56 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v2]
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <kN0wAHx7Jnj2fL9CIOGWzxoxY4rwGG4FSISq51dz1Pg=.27d6c8de-d040-4568-b845-b8fef105318c@github.com>

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

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

 - Merge branch 'master' into JDK-8292695
 - Install SIGBREAK handler only once
 - Fix whitespace
 - 8292695: SIGQUIT and jcmd attaching mechanism does not work with signal chaining library

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9955/files
  - new: https://git.openjdk.org/jdk/pull/9955/files/d1c3f4b7..d226de41

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

  Stats: 79479 lines in 1204 files changed: 35070 ins; 35295 del; 9114 mod
  Patch: https://git.openjdk.org/jdk/pull/9955.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9955/head:pull/9955

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

From manc at openjdk.org  Thu Sep  8 02:45:51 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 02:45:51 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v2]
In-Reply-To: <ATsQyulJFKiocLgmRAVOHGiNsm_ReYtW0foSPJ3qhdo=.868c7893-f88e-43fb-9913-780cc075e690@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <IrBIQPg0G6Lbwuu951LHZFVjKQZisj2G3Y5UtN9wSu0=.b5131639-ca0f-4c30-96c1-4c5873961487@github.com>
 <LUUs0Rouug3twswEwJWrEoyZyhdtmFVS-IaIJ1ELoeI=.1f2be372-4eb2-46b3-a3b1-7b5ae04a4f4d@github.com>
 <xcJ6sXr1wR7LFeKtR8SKOUqbZo6Hw5IgLJZevPXYQvM=.80133df9-de22-41ee-b08e-047dd46e5bcc@github.com>
 <vun3ZP2BkmESqqZ2fDxdzytcPZem9OgHQJIpe0nIT30=.9c9e8168-b478-4a90-8a2c-aab9dde46036@github.com>
 <ATsQyulJFKiocLgmRAVOHGiNsm_ReYtW0foSPJ3qhdo=.868c7893-f88e-43fb-9913-780cc075e690@github.com>
Message-ID: <YwD137sH2Mj6K227iy23jodS7KAQB79C9N4nmtCz9Sk=.cdefef46-87df-42b6-83f3-bc6b7dbb6181@github.com>

On Tue, 30 Aug 2022 06:39:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> My point is that this change seems to allow installation of a BREAK_SIGNAL handler even without -Xrs!
>> 
>> Got it. This is indeed the case. However, prior to [JDK-8279124](https://bugs.openjdk.org/browse/JDK-8279124), HotSpot also behaved in the same way, that it allows installation of a custom BREAK_SIGNAL handler even without -Xrs.
>> 
>> I verified with a modified TestSigquit.java, [here](https://github.com/caoman/jdk/commit/346132aa5af8d59406d0b98567d18d16868a3a32). It tests the "postpre" and "postpost" mode without -Xrs, which both uses libjsig.so:
>> - Without any change, the test times out waiting for the custom signal handler to be called.
>> - With JDK-8279124 [backed out](https://github.com/caoman/jdk/commit/0983baad17d78cf64e1f604abb232e581700a662), OR with this PR, the test passes.
>> 
>> Since HotSpot does not support chaining for SIGQUIT, I think it is OK to leave the behavior undefined if user installs a custom SIGQUIT handler without -Xrs. I.e. the custom handler may or may not work, and it could break HotSpot functionality. libjsig is not designed to prevent installing custom SIGQUIT handler.
>
> I am somewhat surprised by this. My reading of the jsig code is that once the VM has installed a SIGQUIT handler during VM init, then subsequent attempts to install a user handler will add the handler to the set to be chained, but because this is a VM signal the VM will never call that chained handler. With the proposed changes if the SIGQUIT handler has not been installed by the VM then the user handler will be installed directly - though I think the VM's handler would then replace that.
> 
> I find this all rather hard to follow and evaluate. As this seems to fix an issue I guess we can take it as-is and then keep an eye out for any unintended consequences. Though they will likely only come from external users so not something we will know till after the next release.

Updated with tstuefe@'s recommendations. It still keeps the behavior that a user can install a SIGQUIT handler without -Xrs.

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

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

From manc at openjdk.org  Thu Sep  8 02:54:43 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 02:54:43 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <cp8-hKbtbpMGkwy-p1f3e28RajWXgbqeDagWW-9tznw=.539e1521-9ee6-4f3b-a303-40607af7f6a3@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
 <qXt5OL5Gif6tMvzj-9yJdjFYTrrjz9SMYQ6y-XpSU_s=.8fd758c8-d2be-49ee-84a9-178db9bd55eb@github.com>
 <cp8-hKbtbpMGkwy-p1f3e28RajWXgbqeDagWW-9tznw=.539e1521-9ee6-4f3b-a303-40607af7f6a3@github.com>
Message-ID: <EKr4MlYRcLV6Qar8ov_bzsiD9ku4UWexqkT0510hVaA=.3a38c6dc-e781-4cad-bb73-8a8199de2b51@github.com>

On Wed, 7 Sep 2022 20:11:40 GMT, Man Cao <manc at openjdk.org> wrote:

> > But there is nothing that prevents us from moving the SIGQUIT handler installation up in time to the hotspot signal handler initialization. Nobody says the SIGQUIT handler has to be installed after the signal dispatcher thread started.
> 
> Thank you for the great idea and experiment! Let me try this approach and rerun the tests.

Switched to the approach that installs the handler only once.

The SIGQUIT handler has to be installed after jdk_misc_signal_init() has initialized `pending_signals` and `sig_semaphore`, which are used by `os::signal_notify()`.
This means SIGQUIT handler is still installed outside libjsig's JVM_begin_signal_setting/JVM_end_signal_setting window, so it not tracked by libjsig like other HotSpot signals.

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

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

From duke at openjdk.org  Thu Sep  8 03:22:04 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 8 Sep 2022 03:22:04 GMT
Subject: RFR: JDK-8293472: Cgroup: 'stomping of _mount_path' crash if
 manually mounted cg controller exist [v5]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <4CEUue84rGWR4Nut98zGTlUnSjryfHS_Ls1qO4DjD3I=.dfac9f72-290c-4add-967d-74e0a0f17f69@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Change warning to debug log

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/3eed0907..338a0954

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

  Stats: 45 lines in 3 files changed: 25 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10193/head:pull/10193

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

From duke at openjdk.org  Thu Sep  8 03:24:39 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 8 Sep 2022 03:24:39 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v4]
In-Reply-To: <2vh0_4aTFj6ajk_oN-E5QQ0L-03v78QaGRP-PgEEg08=.1c18ddba-110e-49b1-99c0-877499160552@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>
 <2vh0_4aTFj6ajk_oN-E5QQ0L-03v78QaGRP-PgEEg08=.1c18ddba-110e-49b1-99c0-877499160552@github.com>
Message-ID: <xjtJejvVEzRTAPJ72Kh3YDbt29mXcEiUHXLPcZuVYTI=.d1ba8344-4fe6-4ede-8f1a-204bd508b74e@github.com>

On Wed, 7 Sep 2022 09:49:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 136:
> 
>> 134:     if (strstr(cg_infos[controller]._mount_path, "/sys/fs/cgroup") != cg_infos[controller]._mount_path) {
>> 135:       log_warning(os, container)("Duplicate %s controllers detected. Picking %s, skipping %s.",
>> 136:                                  name, mount_path, cg_infos[controller]._mount_path);
> 
> Please demote this to `log_debug` over a `log_warning`.

done

> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 141:
> 
>> 139:     } else {
>> 140:       log_warning(os, container)("Duplicate %s controllers detected. Picking %s, skipping %s.",
>> 141:                                  name, cg_infos[controller]._mount_path, mount_path);
> 
> Please demote this to `log_debug` over `log_warning`.

done

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

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

From duke at openjdk.org  Thu Sep  8 03:32:48 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 8 Sep 2022 03:32:48 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v4]
In-Reply-To: <2vh0_4aTFj6ajk_oN-E5QQ0L-03v78QaGRP-PgEEg08=.1c18ddba-110e-49b1-99c0-877499160552@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <VcWKLunn3NV04NgstMXIp7cMtKrHXJGwDPl0OiE82j8=.ecbecfdd-94e6-4b75-af33-9b32410be90c@github.com>
 <2vh0_4aTFj6ajk_oN-E5QQ0L-03v78QaGRP-PgEEg08=.1c18ddba-110e-49b1-99c0-877499160552@github.com>
Message-ID: <9NmEF2fM7DliArxSIMmlN2i6oVJVPAb2QnkMiqa0eVI=.da41fad6-3778-4150-b587-628b78424b99@github.com>

On Wed, 7 Sep 2022 09:56:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Looks mostly good. https://bugs.openjdk.org/browse/JDK-8270087 seems to be an early sighting of this. It mentions a reproducer, manually mount `/sys/fs/cgroup` from the host into the container. Please write a container test asserting that no warnings get produced. Perhaps use `test/hotspot/jtreg/containers/docker/DockerBasicTest.java` and write a new test method `javaVersionWithCgMounts` or some such, which verifies no warning shows up on stdout.

Thank you very much for the reviewing. I have not noticed JDK-8270087 before, sorry about filing a duplicate jdk bug.

> My testing on cgv2 and cgv1 indicates that we might have a container resource limit detection problem depending on the order of `mountinfo` entries are observed at runtime. Please add memory and cpu limit container detection tests which do `-v /sys/fs/cgroup:/cgroups-in:ro` as a volume mount in addition. Thanks!

The `container resource limit detection problem` is also fixed when there are multiple cgroup fs mount entries, it is caused by multiple setting of root mount path in function `CgroupSubsystemFactory::determine_type`.

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

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

From jianglizhou at google.com  Thu Sep  8 04:07:15 2022
From: jianglizhou at google.com (Jiangli Zhou)
Date: Wed, 7 Sep 2022 21:07:15 -0700
Subject: RFC: Change CDS JAR file validation
In-Reply-To: <CALrW1jzNJvGRg6C0ULjhjvy0DWLRxk7ba5LLALagSmX=ZAX2mg@mail.gmail.com>
References: <d4a49ea8-04c1-6e4d-8f2c-e5a85614b952@oracle.com>
 <CALrW1jzNJvGRg6C0ULjhjvy0DWLRxk7ba5LLALagSmX=ZAX2mg@mail.gmail.com>
Message-ID: <CALrW1jx_Y=NRV73RKyGNgZf5cX7pfSDfYb6qQX3qj=Rc1q2KOw@mail.gmail.com>

On Thu, Sep 1, 2022 at 12:51 PM Jiangli Zhou <jianglizhou at google.com> wrote:
>
> When utilizing CDS for tools in a cloud environment a few years back,
> we ran into the path checking issue. One of the main problems that we
> observed was that the mtime based check was not reliable. Internally,
> we've explored a few potential solutions. One of suggested ideas was
> to compute a checksum of the jar file and store the value in the zip
> central directory. Runtime can then validate the checksum. That can be
> reliable. It may require specification changes.

Some additional details about the idea using the zip central directory
for storing checksum (which was suggested by @martin):

The checksum would be computed at JAR creation time and stored in the
zip central directory. The checksum can be updated when the JAR file
is updated. At CDS image creation time, the JAR checksum could be
obtained and stored in the CDS image header. Runtime can then compare
the checksums to validate compatibility. The advantage is that it
avoids having to compute the checksum at both CDS creation time and
runtime. However, it requires JAR tools to be updated to support that.

>
> Another approach is to provide a runtime flag (e.g.
> -XX:+|-ValidateSharedClassPaths), which can be used to disable the
> problematic jar path checking in use cases where it is safe to do so.
> This is the approach that we have been using for tools that use CDS.
> The tools' JAR files and CDS images are built and released together.
> As the release progresses guarantee the compatibility between the JAR
> file and the CDS archive in these kinds of usages, we can safely
> disable the corresponding path checking. It also minimizes the related
> overhead. I'd like to contribute the related patch in the short term.

Created https://bugs.openjdk.org/browse/JDK-8293526 (apologizing for
duplicating with https://bugs.openjdk.org/browse/JDK-8284692).

Thanks,
Jiangli

>
> Thanks,
> Jiangli
>
> On Wed, Aug 31, 2022 at 9:47 PM Ioi Lam <ioi.lam at oracle.com> wrote:
> >
> > Proposal Summary:
> >
> > Use a digest of a JAR file to detect if the file has changed
> >
> >
> > Background
> > ==========
> >
> > CDS is in effect a caching mechanism -- it needs to make sure that the
> > InstanceKlasses stored in the archive are the same as those parsed from
> > classfiles.
> >
> > To do this, we archive only the classes from (a) the JDK's modules image
> > file and (b) JAR files. We don't archive classes in directories since
> > it's difficult to check if the contents of a directory have changed.
> >
> > At runtime, we assume that (a) didn't change, since we require the exact
> > same JDK build to be used.
> >
> > For (b) we currently do this:
> >
> > (1) Check that -classpath and -Xbootclasspath (absolute paths) are
> > identical between run time and dump time.
> > (2) For each JAR file in cp and bcp, check if its size and modification
> > time has changed.
> > (3) (Something similar happens with the module path ....)
> >
> > We have used this scheme for almost a decade. Note that we avoid reading
> > the JAR files as that may slow down start-up time on old spinning disks.
> > However, as most work-loads run on SSDs now, I believe this is no longer
> > a concern.
> >
> > Recently, we are seeing problems when people deploy CDS inside containers:
> >
> > For (1) the file system structure may different between run time and
> > dump time. We can kludge around this problem by using relative paths
> > instead of absolute paths, but this will make the existing code even
> > more complicated.
> >
> > For (2) when deploying the app, it may not be easy to keep the
> > modification time unchanged (see JDK-8284692).
> >
> >
> > Proposal
> > ========
> >
> > For (1) - don't not compare directory name anymore. Only check that the
> > filename is the same:
> >
> > E.g.
> >
> > Dump:
> >      java -Xshare:dump -cp dir1/Foo.jar:dir2/Bar.jar ..
> >
> > Run:
> >      java -cp dir1/Foo.jar:dir2/Bar.jar ...     [OK]
> > java -cp Foo.jar:Bar.jar ...               [OK]
> >      java -cp Foo.jar:Bxx.jar ... [Fail - changed from Bar.jar to Bxx.jar]
> >
> > For (2)
> >
> > - Check that file size has not changed.
> > - Compute a digest of the file. Check that this has not changed.
> >
> >
> > Digest
> > ======
> >
> > The purpose is not for security or (malicious) tamper detection. It's
> > for guarding against innocent mistakes (forgot to regenerate CDS archive
> > after JAR files have been updated). Therefore, we don't need to run an
> > expensive digest like MD5.
> >
> > Instead, it should be enough to just do a quick XOR digest of the first
> > 128 bytes of the JAR file. Since this part usually contains the
> > META-INF/ directory and its modification time. So it effectively
> > contains the time when this JAR file was created. The timestamp seems to
> > have a 2 second resolution:
> >
> > $ while true; do jar cfm foo.jar MANIFEST.MF HelloWorld.class ; head -c
> > 128 foo.jar | cksum; sleep 2; done
> > 3803507028 128
> > 1857545662 128
> > 916098721 128
> > 3740087168 128
> > 2260752543 128
> > 3257546723 128
> > 2584173820 128
> > ...
> >
> >
> > Advantage:
> >
> > - Make it easier to deploy CDS archive (fewer false negatives)
> > - Simplify logic in the CDS code
> >
> > Risks:
> >
> > - Opening every JAR file may cause a slow down if you have lots of JARs
> > in the classpath running on a slow file system.
> >

From xliu at openjdk.org  Thu Sep  8 06:24:48 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 8 Sep 2022 06:24:48 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  fix MSVC warning C4267
  
  MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
  'size_t' to 'int', possible loss of data

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/8c3efc16..6508429c

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

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

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

From iklam at openjdk.org  Thu Sep  8 06:45:25 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 8 Sep 2022 06:45:25 GMT
Subject: RFR: 8292225: Rename ArchiveBuilder APIs related to source and
 buffered addresses
Message-ID: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>

This is a clean up of the source code to make it more readable. 
- When creating a CDS archive, we first load Java classes and create metadata objects as usual. These are call "source" objects.
- We then copy the source objects into the output buffer at their "buffered addresses".

However, we used a mix of other words to refer to them:

- The word "orig" was also used for the former.
- The words "dumped" and "relocated" were also used for the latter.

This PR renamed the names of functions and parameters to consistently use "source" and "buffered" only. In one case I reordered two fields in a class. There's otherwise no change in the code.

Please see new comments in archiveBuilder.hpp that explains the three types of addresses: "source" vs "buffered" vs "requested".

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

Commit messages:
 - 8292225: Rename ArchiveBuilder APIs related to source and buffered addresses

Changes: https://git.openjdk.org/jdk/pull/10212/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292225
  Stats: 115 lines in 8 files changed: 28 ins; 11 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10212.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10212/head:pull/10212

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

From stuefe at openjdk.org  Thu Sep  8 07:23:42 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Sep 2022 07:23:42 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library
In-Reply-To: <EKr4MlYRcLV6Qar8ov_bzsiD9ku4UWexqkT0510hVaA=.3a38c6dc-e781-4cad-bb73-8a8199de2b51@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <XT8xRw9ou-461QVqWwkMmftfNRFvO49un_4RYFVhl_0=.2e1074c8-c481-4723-963f-fb9ddbfe76b9@github.com>
 <qXt5OL5Gif6tMvzj-9yJdjFYTrrjz9SMYQ6y-XpSU_s=.8fd758c8-d2be-49ee-84a9-178db9bd55eb@github.com>
 <cp8-hKbtbpMGkwy-p1f3e28RajWXgbqeDagWW-9tznw=.539e1521-9ee6-4f3b-a303-40607af7f6a3@github.com>
 <EKr4MlYRcLV6Qar8ov_bzsiD9ku4UWexqkT0510hVaA=.3a38c6dc-e781-4cad-bb73-8a8199de2b51@github.com>
Message-ID: <kT26mRe9xqviEPI8qc6xT2LcAGkb3aifs2ValhP3CvE=.36842081-054a-4cc7-9aad-dac6a9356840@github.com>

On Thu, 8 Sep 2022 02:50:59 GMT, Man Cao <manc at openjdk.org> wrote:

> > > But there is nothing that prevents us from moving the SIGQUIT handler installation up in time to the hotspot signal handler initialization. Nobody says the SIGQUIT handler has to be installed after the signal dispatcher thread started.
> > 
> > 
> > Thank you for the great idea and experiment! Let me try this approach and rerun the tests.
> 
> Switched to the approach that installs the handler only once.
> 
> The SIGQUIT handler has to be installed after jdk_misc_signal_init() has initialized `pending_signals` and `sig_semaphore`, which are used by `os::signal_notify()`. This means SIGQUIT handler is still installed outside libjsig's JVM_begin_signal_setting/JVM_end_signal_setting window, so it not tracked by libjsig like other HotSpot signals.

You can just move `jdk_misc_signal_init` up a notch in `PosixSignals::init()`, to precede hotspot signal initialization. Semaphore initialization does not depend on anything much, its just a `sem_init()`. See my modified example: 

https://github.com/openjdk/jdk/commit/77826cf8253e5bda0ca7e694a2d100e4988d9e38

Then it works as planned, with SIGQUIT now being part of the normal hotspot VM signal installation.

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

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

From xliu at openjdk.org  Thu Sep  8 07:38:58 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 8 Sep 2022 07:38:58 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v2]
In-Reply-To: <kN0wAHx7Jnj2fL9CIOGWzxoxY4rwGG4FSISq51dz1Pg=.27d6c8de-d040-4568-b845-b8fef105318c@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <kN0wAHx7Jnj2fL9CIOGWzxoxY4rwGG4FSISq51dz1Pg=.27d6c8de-d040-4568-b845-b8fef105318c@github.com>
Message-ID: <jTSY9OmZplFxpusvIaEOYnGMCD8aZ0bHBEsghrOd3-M=.7afd6602-7726-4a43-861f-672295d35fa6@github.com>

On Thu, 8 Sep 2022 02:41:56 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8292695
>  - Install SIGBREAK handler only once
>  - Fix whitespace
>  - 8292695: SIGQUIT and jcmd attaching mechanism does not work with signal chaining library

I try it out. yeah, it works! One installation but it will remember early SIGBREAK.

Why do you insist to move jdk_misc_signal_init() before install_signal_handlers()? Is there any difference before and after it?

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

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

From manc at openjdk.org  Thu Sep  8 08:19:47 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 08:19:47 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Move jdk_misc_signal_init() earlier and clarify its comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9955/files
  - new: https://git.openjdk.org/jdk/pull/9955/files/d226de41..339d7eed

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

  Stats: 43 lines in 2 files changed: 22 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9955.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9955/head:pull/9955

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

From manc at openjdk.org  Thu Sep  8 08:28:44 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 08:28:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
Message-ID: <5FqMaBOtCscTwN4n4xLC93lvhlloK_UJkfL-wmHNlcc=.3deb8bc5-08b3-4954-967f-6695c30bf728@github.com>

On Thu, 8 Sep 2022 08:19:47 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move jdk_misc_signal_init() earlier and clarify its comment

Moved `jdk_misc_signal_init()` earlier as Thomas suggested. Now that libjsig can prevent user overriding SIGBREAK later.
For Windows, `jdk_misc_signal_init()` seems appropriate as there's a `SetConsoleCtrlHandler()` above.

>  Why do you insist to move jdk_misc_signal_init() before install_signal_handlers()? Is there any difference before and after it?

Because SIGBREAK's UserHandler() uses the `pending_signals` and `sig_semaphore` variables initialized by `jdk_misc_signal_init()`.

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

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

From manc at openjdk.org  Thu Sep  8 08:28:45 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 08:28:45 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <YwD137sH2Mj6K227iy23jodS7KAQB79C9N4nmtCz9Sk=.cdefef46-87df-42b6-83f3-bc6b7dbb6181@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <IrBIQPg0G6Lbwuu951LHZFVjKQZisj2G3Y5UtN9wSu0=.b5131639-ca0f-4c30-96c1-4c5873961487@github.com>
 <LUUs0Rouug3twswEwJWrEoyZyhdtmFVS-IaIJ1ELoeI=.1f2be372-4eb2-46b3-a3b1-7b5ae04a4f4d@github.com>
 <xcJ6sXr1wR7LFeKtR8SKOUqbZo6Hw5IgLJZevPXYQvM=.80133df9-de22-41ee-b08e-047dd46e5bcc@github.com>
 <vun3ZP2BkmESqqZ2fDxdzytcPZem9OgHQJIpe0nIT30=.9c9e8168-b478-4a90-8a2c-aab9dde46036@github.com>
 <ATsQyulJFKiocLgmRAVOHGiNsm_ReYtW0foSPJ3qhdo=.868c7893-f88e-43fb-9913-780cc075e690@github.com>
 <YwD137sH2Mj6K227iy23jodS7KAQB79C9N4nmtCz9Sk=.cdefef46-87df-42b6-83f3-bc6b7dbb6181@github.com>
Message-ID: <tJ28sOVelBLqEhwBG9bunPZJgXMOlCIHAYF_rodWPyw=.45e4b1d1-32d1-4c1c-8c8e-524199e451fe@github.com>

On Thu, 8 Sep 2022 02:43:46 GMT, Man Cao <manc at openjdk.org> wrote:

>> I am somewhat surprised by this. My reading of the jsig code is that once the VM has installed a SIGQUIT handler during VM init, then subsequent attempts to install a user handler will add the handler to the set to be chained, but because this is a VM signal the VM will never call that chained handler. With the proposed changes if the SIGQUIT handler has not been installed by the VM then the user handler will be installed directly - though I think the VM's handler would then replace that.
>> 
>> I find this all rather hard to follow and evaluate. As this seems to fix an issue I guess we can take it as-is and then keep an eye out for any unintended consequences. Though they will likely only come from external users so not something we will know till after the next release.
>
> Updated with tstuefe@'s recommendations. It still keeps the behavior that a user can install a SIGQUIT handler without -Xrs.

The behavior has changed. Now that with libjsig, user must have -Xrs to install a custom SIGQUIT handler.

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

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

From stuefe at openjdk.org  Thu Sep  8 10:45:43 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Sep 2022 10:45:43 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
Message-ID: <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>

On Thu, 8 Sep 2022 08:19:47 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move jdk_misc_signal_init() earlier and clarify its comment

Can you also add a test that checks that:

if VM is started with -Xrs, and we send a SIGQUIT, the VM shall crash with a core. The crash should look like a system crash, not an hs-err file crash, like this:


Quit (core dumped)


which assures us that no hotspot signal handler is installed and we take therefore the default action on SIGQUIT.

If this string is OS dependent and gives us headaches, the test should check at least that the process exit code is not 0.

And of course the VM should be started with tiny heap etc such to make sure the core file generated will be tiny.

src/hotspot/os/posix/signals_posix.cpp line 1319:

> 1317:     // Also note that HotSpot does NOT support signal chaining for BREAK_SIGNAL.
> 1318:     // Applications that require a custom BREAK_SIGNAL handler should run with
> 1319:     // -XX:+ReduceSignalUsage. Otherwise if libjsig is used together with

Maybe also mention "AllowUserSignalHandlers"

test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 38:

> 36:  * @bug 8292695
> 37:  * @summary Check that Ctrl-\ causes HotSpot VM to print a full thread dump when signal chaining is used.
> 38:  * @requires os.family == "linux" | os.family == "mac"

Why not just !Windows? Aix, the BSDs, Solaris if this is downported should work too.

test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 62:

> 60:         public static void main(String[] argv) throws Exception {
> 61:             ProcessUtils.sendCtrlBreak();
> 62:             System.out.println("Done!");

Maybe don't finish right away but wait a second or two, for dispatcher thread on slow systems to catch up.

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

Changes requested by stuefe (Reviewer).

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

From stuefe at openjdk.org  Thu Sep  8 11:32:46 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Sep 2022 11:32:46 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
Message-ID: <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>

On Thu, 8 Sep 2022 06:24:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MSVC warning C4267
>   
>   MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
>   'size_t' to 'int', possible loss of data

Hi Xin,

getting closer. Remarks inline.

Cheers, Thomas

src/hotspot/share/logging/logAsyncWriter.cpp line 64:

> 62:   size_t sz = align_up(sizeof(Message) + len, sizeof(void*));
> 63: 
> 64:   if (_pos + sz <= _capacity || output == nullptr/*token*/) {

I don't understand this. The push token thing is not zero-sized, so what happens if we go over capacity? Or, in other words, if we fill the buffer with push tokens only, won't we overwrite and crash?

src/hotspot/share/logging/logAsyncWriter.cpp line 80:

> 78: AsyncLogWriter::Message* AsyncLogWriter::Buffer::Iterator::next() {
> 79:   assert(_curr < _buf._pos, "sanity check");
> 80:   auto msg = reinterpret_cast<Message*>(_buf._buf + _curr);

Is there a reason why Iterator needs to directly access _buf? Why not give Buffer a `const char* base() const` ? Also, why return a non-const ptr?

src/hotspot/share/logging/logAsyncWriter.cpp line 89:

> 87:   // To save space and streamline execution, we just ignore null message.
> 88:   // client should use "" instead.
> 89:   if (msg == nullptr) return;

Is that even valid? Who logs with a NULL message? If that is valid, why treat it differently than "", and if not, why not just assert here?

src/hotspot/share/logging/logAsyncWriter.cpp line 123:

> 121: 
> 122:   size_t page_size = os::vm_page_size();
> 123:   size_t size = align_up(AsyncLogBufferSize / 2, page_size);

Why page size alignment? Would also interfere with my proposal of testing with a tiny buffer.

src/hotspot/share/logging/logAsyncWriter.hpp line 65:

> 63:                           ResourceObj::C_HEAP,
> 64:                           mtLogging>;
> 65:   class Message {

Maybe add a small comment about the memory layout. ("variable sized structure with zero-terminated string following the header").

src/hotspot/share/logging/logAsyncWriter.hpp line 97:

> 95:     size_t _capacity;
> 96: 
> 97:    public:

Make NONCOPYABLE?

src/hotspot/share/logging/logAsyncWriter.hpp line 99:

> 97:    public:
> 98:     Buffer(size_t capacity);
> 99:     ~Buffer();

I'd remove this destructor, or make it private, or at least add a ShouldNotReachHere. IIUC we never free the buffer, and that is by design.

src/hotspot/share/logging/logAsyncWriter.hpp line 109:

> 107:       _capacity = value;
> 108:       return old;
> 109:     }

Actually, I would prefer it if you did not shrink the buffer dynamically, since this is not a supported scenario and may cause unforeseen problems (besides making the code harder to argue about). 

You could just leave buffer size immutable after creation and instead add another test variation to your `AsyncLogGtest.java` where you start with a tiny tiny buffer size, and then run all your gtests with it. More test coverage, and we don't need the test coding here.

(Side note, I see that in AsyncLogGtest.java you run all tests inside a single `@test` scope. If you split them up and give them speaking id's, these tests can run in parallel. For examples, see e.g. the NMTGtests. The duplication of the test section is annoying, but the parallelization of tests you get for free is cool. Also, you can start them individually if you want to reproduce a test error.)

src/hotspot/share/logging/logAsyncWriter.hpp line 121:

> 119: 
> 120:       bool is_empty() const {
> 121:         return _curr >= _buf._pos;

This should never be larger than `_buf._pos`, right? Also, I would not name it `is_empty`, that's confusing, but rather something like `eof()` or `at_end()` or somesuch.

src/hotspot/share/logging/logAsyncWriter.hpp line 124:

> 122:       }
> 123: 
> 124:       Message* next();

Why non-const?

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

Changes requested by stuefe (Reviewer).

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

From stuefe at openjdk.org  Thu Sep  8 11:32:46 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Sep 2022 11:32:46 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]
In-Reply-To: <PZ6mIJYPObwysQ4yk1UPF-7B1q-G8g1YZtZ0epWIk2E=.c08317ac-48e9-448b-921c-a371b5b24f26@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <HUOAbm1YW9iyCIYBOB1ToxZrd7kiolw1XSKQciqF_0M=.ce08a9b9-b555-47d7-b612-606bd165c745@github.com>
 <S2TTUez4phT3vOnE3yOHBc7jemgVQfWAEomr1AE97fc=.9feaebf0-cf43-43e1-8899-a91dc8e3fb40@github.com>
 <1fnBHDK7Ssa5lGsQec1Z4DZVdIFStuZf_rBKxu1QnXc=.6347c2a5-7b59-4501-8d4b-815147a71a54@github.com>
 <NoMkJlTYkhJUvD3Akrvj2F3c3vi3CSZKx9-NWmgxDJQ=.046a1aef-8614-4f8c-b1b9-8f726a8a4bd7@github.com>
 <PZ6mIJYPObwysQ4yk1UPF-7B1q-G8g1YZtZ0epWIk2E=.c08317ac-48e9-448b-921c-a371b5b24f26@github.com>
Message-ID: <wSpghkIf7A2aysnfhEDSy9jnxX_wjOVNx5N3q546uBI=.3df65674-9b9a-4f2b-819e-f38d19341492@github.com>

On Thu, 8 Sep 2022 00:32:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I prefer trailing 0 because `AsyncLogMessage::message()` can be treated as a valid c-string and pass to LogFileStreamOutput. If so, `len` is optional indeed. The benefit of `len` is that we can iterate buffer faster. We will have O(1) time-complexity instead of O(len) in `Buffer::Iterator::next() `
>> 
>> I see your point. It's more elegant to use `implicit` message. The reason I need to handle `msg= nullptr` is that flushing Token uses it. I can replace it with "" instead.
>
> I update to use in-place new for AsyncLogMessage objects. For safety, I change AsyncLogMessage to a nested class and rename it to 'Message'. It's private so it's not accessible by outside.
> 
> Previously, we had at least one extra copy of `LogDecorations`. Now it aligns with c-str message. We materialize them only in constructor. Because we have to support asynchronous execution, this is optimal.

> I prefer trailing 0 because `AsyncLogMessage::message()` can be treated as a valid c-string and pass to LogFileStreamOutput. If so, `len` is optional indeed. The benefit of `len` is that we can iterate buffer faster. We will have O(1) time-complexity instead of O(len) in `Buffer::Iterator::next() `

That's what I meant. Keep the trailing '\0' but for performance reasons cache length too in whatever size is sufficient. I see you kept using strlen. Now you do two strlen + align calls, one in push_back, one on iteration.

> 
> I see your point. It's more elegant to use `implicit` message. The reason I need to handle `msg= nullptr` is that flushing Token uses it. I can replace it with "" instead.

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

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

From sgehwolf at openjdk.org  Thu Sep  8 12:03:03 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 8 Sep 2022 12:03:03 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v5]
In-Reply-To: <4CEUue84rGWR4Nut98zGTlUnSjryfHS_Ls1qO4DjD3I=.dfac9f72-290c-4add-967d-74e0a0f17f69@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <4CEUue84rGWR4Nut98zGTlUnSjryfHS_Ls1qO4DjD3I=.dfac9f72-290c-4add-967d-74e0a0f17f69@github.com>
Message-ID: <KaG-fNN89Bb5Q8ux9BQyXSFzoPB6gavrBchrXpYb5is=.7f0c1526-195e-4bb1-93a5-e80f885b8d40@github.com>

On Thu, 8 Sep 2022 03:22:04 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change warning to debug log

We definitely need regression tests for memory/cpu limits with those additional cgroup mounts. 
Please take a look at `test/hotspot/jtreg/containers/docker/TestCPUAwareness.java` and `test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java`

For cgroups v2 the issues isn't fixed. The paths for cg v2 are being set here:
https://github.com/openjdk/jdk/blob/98da03af50e2372817a7b5e381eea5ee6f2cb919/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L303..L313.

Example of running (with your patch on a cg v2 system):


$ sudo podman run --rm -ti --memory=300M --memory-swap=300M -v /sys/fs/cgroup:/cgroup-in:ro -v $(pwd)/jdk20-jdk:/opt/jdk:z fedora:36 /opt/jdk/bin/java -Xlog:os+container=trace -version 2>&1 | grep 'Memory Limit'
[0.001s][trace][os,container] Memory Limit is: -2
[0.055s][trace][os,container] Memory Limit is: -2


Expected:


[0.001s][trace][os,container] Memory Limit is: 314572800
[0.068s][trace][os,container] Memory Limit is: 314572800

test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 91:

> 89:             new DockerRunOptions(imageNameAndTag, "/jdk/bin/java", "-version")
> 90:             .addJavaOpts("-Xlog:os+container=trace")
> 91:             .addDockerOpts("-v", "/sys/fs/cgroup:/cgroups-in:ro");

I'd suggest, to first add a test which verifies that without `-Xlog:os+container=trace` option, `java -version` on such a container doesn't print **any** `os+container` logs (it used to print a warning in the` -v /sys/fs/cgroup:/cgroups-in:ro` case). That's all this test should verify.

test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 102:

> 100:             .shouldContain("Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us")
> 101:             .shouldContain("Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us")
> 102:             .shouldContain("Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes");

Those are all cgroups v1 specific paths, so the test will fail when run on cgroups v2. I don't think that's necessary. Just remove those and rely on new test cases in `test/hotspot/jtreg/containers/docker/TestCPUAwareness.java` and `test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java`

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

Changes requested by sgehwolf (Reviewer).

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

From stuefe at openjdk.org  Thu Sep  8 16:16:36 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Sep 2022 16:16:36 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v5]
In-Reply-To: <VRpa6-opEssOIzap8PejKkq4H_f9ByVchcsCHyUNyqQ=.3c1f67aa-4a6d-49bd-ad39-3f04628e7671@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
 <zhmKyAlUo5gpadIIxuOgaa3nszIKDtmfsuwd0sJTd4A=.85d1ff75-1554-420b-ba99-4f6ebd1847e6@github.com>
 <Bb5HWPlCZG6yJEbX3sa0MReCmBdZtYGnyh6vcQ39zSU=.9be9fc24-433a-4070-bcd9-16542168e5d2@github.com>
 <VRpa6-opEssOIzap8PejKkq4H_f9ByVchcsCHyUNyqQ=.3c1f67aa-4a6d-49bd-ad39-3f04628e7671@github.com>
Message-ID: <y-voNU0VMgxQpG7qvSL_2YNUOfiiuwwfsW-mm86NZHg=.4c3258ee-88cf-43ea-91a2-194b3d98dcf6@github.com>

On Wed, 7 Sep 2022 09:09:52 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

> >To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL.
> 
> 
> 
> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this.
> 
> 
> 
> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets.

The early initialization of UL at lib load time is certainly a pain. 

But there are other things too, other code running before initialisation, and then there is the case of non-attached threads and signal handling, etc.

I would be happy if this primitive was usable with Thread.current == Null. Otherwise you limit the future usefulness, and whatever code people use this lock in will also not be usable in these corner cases. 

If it does not cost too much complexity.

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

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

From dcubed at openjdk.org  Thu Sep  8 16:28:54 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Sep 2022 16:28:54 GMT
Subject: RFR: 8293548: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
Message-ID: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>

A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.
This time for sure Rocky! I've included the "#id1" sub-test identifier.

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

Commit messages:
 - 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64

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

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

From ccheung at openjdk.org  Thu Sep  8 16:28:55 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 8 Sep 2022 16:28:55 GMT
Subject: RFR: 8293548: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
References: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
Message-ID: <GFE5C7Bb3ghbVW0yS3czEcqzCmm0B8ZNssNrTjb92do=.aebb2a9c-8b57-4fed-b9c7-31e27c9484dc@github.com>

On Thu, 8 Sep 2022 16:19:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.
> This time for sure Rocky! I've included the "#id1" sub-test identifier.

LGTM

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

Marked as reviewed by ccheung (Reviewer).

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

From azvegint at openjdk.org  Thu Sep  8 16:28:56 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 8 Sep 2022 16:28:56 GMT
Subject: RFR: 8293548: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
References: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
Message-ID: <jqJcKE6Jcj83H4QHs3EaUonhLYR6s7Es2PYMnJC0XP8=.a3c8346a-cebc-47b8-8e60-8635bf7f735a@github.com>

On Thu, 8 Sep 2022 16:19:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.
> This time for sure Rocky! I've included the "#id1" sub-test identifier.

Marked as reviewed by azvegint (Reviewer).

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

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

From dcubed at openjdk.org  Thu Sep  8 16:33:45 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Sep 2022 16:33:45 GMT
Subject: RFR: 8293548: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <GFE5C7Bb3ghbVW0yS3czEcqzCmm0B8ZNssNrTjb92do=.aebb2a9c-8b57-4fed-b9c7-31e27c9484dc@github.com>
References: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
 <GFE5C7Bb3ghbVW0yS3czEcqzCmm0B8ZNssNrTjb92do=.aebb2a9c-8b57-4fed-b9c7-31e27c9484dc@github.com>
Message-ID: <4hmPijOw7DfgSk2_cLK31qNmC2U0xBDTk7xobErGICY=.4e6dc753-cb1e-4b0f-a2bb-4e86b28f0466@github.com>

On Thu, 8 Sep 2022 16:24:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.
>> This time for sure Rocky! I've included the "#id1" sub-test identifier.
>
> LGTM

@calvinccheung and @azvegint - Thanks for the fast reviews!

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

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

From dcubed at openjdk.org  Thu Sep  8 16:33:47 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Sep 2022 16:33:47 GMT
Subject: Integrated: 8293548: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
References: <EEXVqMPUhZLFFMhIhohC-Ko_7mLi-_ZWc0qzLU8_so0=.423563a9-7493-4e08-9ad4-1fdf5880fe44@github.com>
Message-ID: <5-mPFtns7p2SzFNs4XiG1qLhkputuCBHamF-2HVs0o4=.2601b85e-0544-49e3-9f4b-d7885c3d228d@github.com>

On Thu, 8 Sep 2022 16:19:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.
> This time for sure Rocky! I've included the "#id1" sub-test identifier.

This pull request has now been integrated.

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

8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64

Reviewed-by: ccheung, azvegint

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

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

From manc at openjdk.org  Thu Sep  8 18:19:48 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 18:19:48 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
Message-ID: <26GKfcRaODK8VoqarmerqneA3ovxGLZon6Urg_1PcEQ=.f7119839-51f5-47e7-8dec-216fbeca33dc@github.com>

On Thu, 8 Sep 2022 10:19:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move jdk_misc_signal_init() earlier and clarify its comment
>
> test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 38:
> 
>> 36:  * @bug 8292695
>> 37:  * @summary Check that Ctrl-\ causes HotSpot VM to print a full thread dump when signal chaining is used.
>> 38:  * @requires os.family == "linux" | os.family == "mac"
> 
> Why not just !Windows? Aix, the BSDs, Solaris if this is downported should work too.

https://docs.oracle.com/en/java/javase/17/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D says signal chaining is available only on Linux and macOS. Should the doc be updated?

Also, the tests in `test/hotspot/jtreg/runtime/signal/` have "!windows && !aix". I'm not sure why they exclude aix, should this test exclude aix similarly?

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

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

From duke at openjdk.org  Thu Sep  8 18:27:48 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 8 Sep 2022 18:27:48 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v5]
In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
Message-ID: <STAzoizcEnaSMHD5e5yTfpNnOMWtZATuNutchCndu-M=.093a78a5-067d-41d2-83f5-e25dc43ff08d@github.com>

On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot?
>> 
>> This PR does 3 things:
>> 
>> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot
>> * Adds some new utilities for writing multi-threaded tests.
>> * Adds some tests for MRSW Mutex using these new utilities
>> 
>> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714
>> 
>> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

People want:

1. Nullable threads
2. PlatformMonitor
3. Monitor

3. won't work with 1., as it requires a `Thread` thread, so that will require two different ReadWriteLocks (or method impls).

When we pick 3. we also have to make a decision on whether to support waiting without safepoints or not, making the behavior of ReadWriteLock a bit more complicated and perhaps opaque. Developers reading the code using this lock should preferably know what it does and what the implications are of using it.

The right answer is probably to make a `PlatformReadWriteLock` and a `ReadWriteLock`, going with convention here.

So there are a lot of different choices to be made here. On top of that we have the actual implementation, whose issues are yet to be revealed to us.

I'd like to quote David Holmes here:

>Whether this RWL implementation will turn out to be useful for any existing subsystems without exhibiting performance pathologies or bad interactions with existing synchronization code is just something we will have to see. However, as we tend not to encourage unused code it would perhaps be better to delay integration of this until there is an *actual usecase ready for it*.

I have a use case for this in UL. This is the use case which I will develop this patch towards. If new use cases arises, then patches can be made to this code to supply more use cases.

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

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

From manc at openjdk.org  Thu Sep  8 21:41:44 2022
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Sep 2022 21:41:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
Message-ID: <kMaVTMP_LJQ-reK5ZQqZYMTj-WhHLUoKX6MgwC59Fro=.24d1d97c-065a-4baf-9721-2d8355f14cd0@github.com>

On Thu, 8 Sep 2022 08:47:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move jdk_misc_signal_init() earlier and clarify its comment
>
> src/hotspot/os/posix/signals_posix.cpp line 1319:
> 
>> 1317:     // Also note that HotSpot does NOT support signal chaining for BREAK_SIGNAL.
>> 1318:     // Applications that require a custom BREAK_SIGNAL handler should run with
>> 1319:     // -XX:+ReduceSignalUsage. Otherwise if libjsig is used together with
> 
> Maybe also mention "AllowUserSignalHandlers"

The SIGBREAK handler does not seem to honor `-XX:+AllowUserSignalHandlers`. It is still installed even with `-XX:+AllowUserSignalHandlers`.

Perhaps it can be addressed separately later? As commented in https://bugs.openjdk.org/browse/JDK-8293466, I haven't seen a real use case for +AllowUserSignalHandlers, so I'd vote for deprecating `AllowUserSignalHandlers` for removal in the future.

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

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

From stuefe at openjdk.org  Fri Sep  9 05:25:38 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Sep 2022 05:25:38 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <kMaVTMP_LJQ-reK5ZQqZYMTj-WhHLUoKX6MgwC59Fro=.24d1d97c-065a-4baf-9721-2d8355f14cd0@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
 <kMaVTMP_LJQ-reK5ZQqZYMTj-WhHLUoKX6MgwC59Fro=.24d1d97c-065a-4baf-9721-2d8355f14cd0@github.com>
Message-ID: <BKckZa__rM4O6z72KpD9vEm3fHVhMlXQXWW71UvLxB0=.5b5fd5f4-585f-4ca6-87d1-ce7763d827a1@github.com>

On Thu, 8 Sep 2022 21:38:14 GMT, Man Cao <manc at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1319:
>> 
>>> 1317:     // Also note that HotSpot does NOT support signal chaining for BREAK_SIGNAL.
>>> 1318:     // Applications that require a custom BREAK_SIGNAL handler should run with
>>> 1319:     // -XX:+ReduceSignalUsage. Otherwise if libjsig is used together with
>> 
>> Maybe also mention "AllowUserSignalHandlers"
>
> The SIGBREAK handler does not seem to honor `-XX:+AllowUserSignalHandlers`. It is still installed even with `-XX:+AllowUserSignalHandlers`.
> 
> Perhaps it can be addressed separately later? As commented in https://bugs.openjdk.org/browse/JDK-8293466, I haven't seen a real use case for +AllowUserSignalHandlers, so I'd vote for deprecating `AllowUserSignalHandlers` for removal in the future.

Okay for separate addressing. Deprecating may not be an option though, depending on how seriously we take backward compatibility.

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

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

From stuefe at openjdk.org  Fri Sep  9 05:35:44 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Sep 2022 05:35:44 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <26GKfcRaODK8VoqarmerqneA3ovxGLZon6Urg_1PcEQ=.f7119839-51f5-47e7-8dec-216fbeca33dc@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
 <26GKfcRaODK8VoqarmerqneA3ovxGLZon6Urg_1PcEQ=.f7119839-51f5-47e7-8dec-216fbeca33dc@github.com>
Message-ID: <3swlTv29zqTI36QdOn3xTaxPjwbqwqNFrWH6u3fi4FM=.d2e1caf2-0a37-44f3-ae2b-896fcabadf6c@github.com>

On Thu, 8 Sep 2022 18:17:29 GMT, Man Cao <manc at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 38:
>> 
>>> 36:  * @bug 8292695
>>> 37:  * @summary Check that Ctrl-\ causes HotSpot VM to print a full thread dump when signal chaining is used.
>>> 38:  * @requires os.family == "linux" | os.family == "mac"
>> 
>> Why not just !Windows? Aix, the BSDs, Solaris if this is downported should work too.
>
> https://docs.oracle.com/en/java/javase/17/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D says signal chaining is available only on Linux and macOS. Should the doc be updated?
> 
> Also, the tests in `test/hotspot/jtreg/runtime/signal/` have "!windows && !aix". I'm not sure why they exclude aix, should this test exclude aix similarly?

Well, Solaris support was removed from JDK in 16, but older releases still support it, see: https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html#GUID-F012840D-8E5A-4B6D-8E49-0129A9EE46DB.

As  for AIX, the reason given for the exclusions in other tests is that we cannot run in the primordial thread on AIX. That is true but I'm not sure what this has to do with the signal tests, and I believe libjsig and the other stuff should just work on AIX. I have to dig in our older sources (this stems from the pre-OpenJDK times at SAP).

For now, I'd use !windows && !aix. AIX we can take care of later, but Solaris I would like to support here. Because of backporting, mainly.

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

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

From duke at openjdk.org  Fri Sep  9 05:39:55 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Fri, 9 Sep 2022 05:39:55 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v6]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <MNT-OYLz7OJettGEip0QHq7Y_y9gsT9oxInv-Osg5mM=.69331986-f817-40d2-b3a0-3b7a088ef8d6@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Fix for cgroup v2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/338a0954..5b73d9dd

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

  Stats: 74 lines in 5 files changed: 48 ins; 9 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10193/head:pull/10193

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

From stuefe at openjdk.org  Fri Sep  9 05:40:42 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Sep 2022 05:40:42 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v5]
In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
Message-ID: <6mmC3ErQQCYIn3nhBfSlyq412H7ciZv1qgZsGViuTsQ=.fff7d776-7dc0-4736-9f8a-edb36dfb34a7@github.com>

On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot?
>> 
>> This PR does 3 things:
>> 
>> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot
>> * Adds some new utilities for writing multi-threaded tests.
>> * Adds some tests for MRSW Mutex using these new utilities
>> 
>> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714
>> 
>> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

> People want:
> 
> 1. Nullable threads
> 2. PlatformMonitor
> 3. Monitor
> 4. won't work with 1., as it requires a `Thread` thread, so that will require two different ReadWriteLocks (or method impls).
> 
> When we pick 3. we also have to make a decision on whether to support waiting without safepoints or not, making the behavior of ReadWriteLock a bit more complicated and perhaps opaque. Developers reading the code using this lock should preferably know what it does and what the implications are of using it.
> 
> The right answer is probably to make a `PlatformReadWriteLock` and a `ReadWriteLock`, going with convention here.
> 
> So there are a lot of different choices to be made here. On top of that we have the actual implementation, whose issues are yet to be revealed to us.
> 
> I'd like to quote David Holmes here:
> 
> > Whether this RWL implementation will turn out to be useful for any existing subsystems without exhibiting performance pathologies or bad interactions with existing synchronization code is just something we will have to see. However, as we tend not to encourage unused code it would perhaps be better to delay integration of this until there is an _actual usecase ready for it_.
> 
> I have a use case for this in UL. This is the use case which I will develop this patch towards. If new use cases arises, then patches can be made to this code to supply more use cases.

My use case is for the NMT malloc site table, which gives us the same restrictions as UL (being pre-init-able).

Note that even if you move UL initialization up, UL should still work without Thread==NULL in my opinion, since logging is one of the things that should work ideally always.

BTW, I am trying to get this: https://github.com/openjdk/jdk/pull/10178 into JDK, which may give you an easy option to test the mark with Thread==NULL in gtests.

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

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

From duke at openjdk.org  Fri Sep  9 05:43:48 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Fri, 9 Sep 2022 05:43:48 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v5]
In-Reply-To: <KaG-fNN89Bb5Q8ux9BQyXSFzoPB6gavrBchrXpYb5is=.7f0c1526-195e-4bb1-93a5-e80f885b8d40@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <4CEUue84rGWR4Nut98zGTlUnSjryfHS_Ls1qO4DjD3I=.dfac9f72-290c-4add-967d-74e0a0f17f69@github.com>
 <KaG-fNN89Bb5Q8ux9BQyXSFzoPB6gavrBchrXpYb5is=.7f0c1526-195e-4bb1-93a5-e80f885b8d40@github.com>
Message-ID: <-vH2bgTv_vS1DFgG4nRB7GJ-oB0tsgJ5cR-XpFzB4hs=.363cc7d8-86a5-4707-b212-0f87cd10c76f@github.com>

On Thu, 8 Sep 2022 11:57:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> We definitely need regression tests for memory/cpu limits with those additional cgroup mounts. Please take a look at `test/hotspot/jtreg/containers/docker/TestCPUAwareness.java` and `test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java`
> 
> For cgroups v2 the issues isn't fixed. The paths for cg v2 are being set here: https://github.com/openjdk/jdk/blob/98da03af50e2372817a7b5e381eea5ee6f2cb919/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L303..L313.
> 
> Example of running (with your patch on a cg v2 system):
> 
> ```
> $ sudo podman run --rm -ti --memory=300M --memory-swap=300M -v /sys/fs/cgroup:/cgroup-in:ro -v $(pwd)/jdk20-jdk:/opt/jdk:z fedora:36 /opt/jdk/bin/java -Xlog:os+container=trace -version 2>&1 | grep 'Memory Limit'
> [0.001s][trace][os,container] Memory Limit is: -2
> [0.055s][trace][os,container] Memory Limit is: -2
> ```
> 
> Expected:
> 
> ```
> [0.001s][trace][os,container] Memory Limit is: 314572800
> [0.068s][trace][os,container] Memory Limit is: 314572800
> ```


I have add a cgroup v2 test with duplicate mount info, now it's working for cgroup v2.

> test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 91:
> 
>> 89:             new DockerRunOptions(imageNameAndTag, "/jdk/bin/java", "-version")
>> 90:             .addJavaOpts("-Xlog:os+container=trace")
>> 91:             .addDockerOpts("-v", "/sys/fs/cgroup:/cgroups-in:ro");
> 
> I'd suggest, to first add a test which verifies that without `-Xlog:os+container=trace` option, `java -version` on such a container doesn't print **any** `os+container` logs (it used to print a warning in the` -v /sys/fs/cgroup:/cgroups-in:ro` case). That's all this test should verify.

done

> test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 102:
> 
>> 100:             .shouldContain("Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us")
>> 101:             .shouldContain("Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us")
>> 102:             .shouldContain("Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes");
> 
> Those are all cgroups v1 specific paths, so the test will fail when run on cgroups v2. I don't think that's necessary. Just remove those and rely on new test cases in `test/hotspot/jtreg/containers/docker/TestCPUAwareness.java` and `test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java`

done

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

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

From manc at openjdk.org  Fri Sep  9 08:27:41 2022
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Sep 2022 08:27:41 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  address comments in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9955/files
  - new: https://git.openjdk.org/jdk/pull/9955/files/339d7eed..efed3b50

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

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

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

From manc at openjdk.org  Fri Sep  9 08:33:00 2022
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Sep 2022 08:33:00 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <BKckZa__rM4O6z72KpD9vEm3fHVhMlXQXWW71UvLxB0=.5b5fd5f4-585f-4ca6-87d1-ce7763d827a1@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
 <kMaVTMP_LJQ-reK5ZQqZYMTj-WhHLUoKX6MgwC59Fro=.24d1d97c-065a-4baf-9721-2d8355f14cd0@github.com>
 <BKckZa__rM4O6z72KpD9vEm3fHVhMlXQXWW71UvLxB0=.5b5fd5f4-585f-4ca6-87d1-ce7763d827a1@github.com>
Message-ID: <OQIIYETNF6IbKCXhtux0dIFw5fpy1afS4MQSacIpwa4=.4c25c319-fc0c-4819-80ba-2c55088cb448@github.com>

On Fri, 9 Sep 2022 05:21:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The SIGBREAK handler does not seem to honor `-XX:+AllowUserSignalHandlers`. It is still installed even with `-XX:+AllowUserSignalHandlers`.
>> 
>> Perhaps it can be addressed separately later? As commented in https://bugs.openjdk.org/browse/JDK-8293466, I haven't seen a real use case for +AllowUserSignalHandlers, so I'd vote for deprecating `AllowUserSignalHandlers` for removal in the future.
>
> Okay for separate addressing. Deprecating may not be an option though, depending on how seriously we take backward compatibility.

Thanks. Filed https://bugs.openjdk.org/browse/JDK-8293580.

>> https://docs.oracle.com/en/java/javase/17/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D says signal chaining is available only on Linux and macOS. Should the doc be updated?
>> 
>> Also, the tests in `test/hotspot/jtreg/runtime/signal/` have "!windows && !aix". I'm not sure why they exclude aix, should this test exclude aix similarly?
>
> Well, Solaris support was removed from JDK in 16, but older releases still support it, see: https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html#GUID-F012840D-8E5A-4B6D-8E49-0129A9EE46DB.
> 
> As  for AIX, the reason given for the exclusions in other tests is that we cannot run in the primordial thread on AIX. That is true but I'm not sure what this has to do with the signal tests, and I believe libjsig and the other stuff should just work on AIX. I have to dig in our older sources (this stems from the pre-OpenJDK times at SAP).
> 
> For now, I'd use !windows && !aix. AIX we can take care of later, but Solaris I would like to support here. Because of backporting, mainly.

Done. Thanks for the details!

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

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

From manc at openjdk.org  Fri Sep  9 08:33:00 2022
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Sep 2022 08:33:00 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
Message-ID: <bWbVeySL_NVfDT3AqezBI25MtjXFoYNPtEIRg3n5UIQ=.4a2dcb2b-e20a-4f9f-9bc7-d99f93f9229e@github.com>

On Thu, 8 Sep 2022 10:28:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move jdk_misc_signal_init() earlier and clarify its comment
>
> test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 62:
> 
>> 60:         public static void main(String[] argv) throws Exception {
>> 61:             ProcessUtils.sendCtrlBreak();
>> 62:             System.out.println("Done!");
> 
> Maybe don't finish right away but wait a second or two, for dispatcher thread on slow systems to catch up.

Done.

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

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

From manc at openjdk.org  Fri Sep  9 08:39:05 2022
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Sep 2022 08:39:05 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v3]
In-Reply-To: <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <c8XQgT9I2VnKX128RQ_CcUnWZd1QuoaZddBOcw2X3ew=.767d926c-000e-4925-b426-2f49842ae883@github.com>
 <FzlRGPbffF_AoNrxy8lupiLN3I4q9xUVy9xAGooPPsU=.ad1cf339-9d92-4d5d-b1fd-ae437c1b74e9@github.com>
Message-ID: <gdpnJjX99Ha5lwtZAV_PGfbkbmfge4Lzjjrd6OXbQco=.1e72e640-3f2e-4c6f-b9c2-956f3a9579ef@github.com>

On Thu, 8 Sep 2022 10:41:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Can you also add a test that checks that:
>
> if VM is started with -Xrs, and we send a SIGQUIT, the VM shall crash with a core. The crash should look like a system crash, not an hs-err file crash, like this:

I struggled to get this to work. I found out it is due to https://bugs.openjdk.org/browse/JDK-8234262, and ProcessBuilder changes how SIGQUIT is handled in the subprocess. This is further complicated by how jtreg runs the parent process. The workaround (passing -Xrs to the parent process) does not work through jtreg using "main/othervm -Xrs".

I uploaded the not-working test in here: https://github.com/caoman/jdk/commit/73e3a5f90985fcad9a383c704429cefb07011932

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

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

From sgehwolf at openjdk.org  Fri Sep  9 10:18:46 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 9 Sep 2022 10:18:46 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v6]
In-Reply-To: <MNT-OYLz7OJettGEip0QHq7Y_y9gsT9oxInv-Osg5mM=.69331986-f817-40d2-b3a0-3b7a088ef8d6@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <MNT-OYLz7OJettGEip0QHq7Y_y9gsT9oxInv-Osg5mM=.69331986-f817-40d2-b3a0-3b7a088ef8d6@github.com>
Message-ID: <PreCY_JN2ObynSM9YXXIpl93Pr396srA9mWH03UFb5A=.85c553a5-78bd-4b34-a52a-6a9e476521f9@github.com>

On Fri, 9 Sep 2022 05:39:55 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for cgroup v2

Thanks for the updates! A few more thoughts.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 126:

> 124: }
> 125: 
> 126: void CgroupSubsystemFactory::set_controller_pathes(CgroupInfo* cg_infos,

Typo: `set_controller_paths`

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 346:

> 344:                                    cg_infos[0]._mount_path, tmp_mount_point);
> 345:         }
> 346:       }

Couldn't we simplify this? For example by changing:


      if (!cgroupv2_mount_point_found && strcmp("cgroup2", tmp_fs_type) == 0) {
        cgroupv2_mount_point_found = true;
        any_cgroup_mounts_found = true;
        for (int i = 0; i < CG_INFO_LENGTH; i++) {
          assert(cg_infos[i]._mount_path == NULL, "_mount_path memory stomping");
          cg_infos[i]._mount_path = os::strdup(tmp_mount_point);
        }


to something like this:


      if (strcmp("cgroup2", tmp_fs_type) == 0) {
        cgroupv2_mount_point_found = true;
        any_cgroup_mounts_found = true;
        for (int i = 0; i < CG_INFO_LENGTH; i++) {
          set_controller_paths(cg_infos, i, "(cg2, unified)", tmpmount, tmproot);
        }


It would entail modifying the `sscanf` to something like `sscanf(p, "%*d %*d %*d:%*d %s %s %*[^-]- %s %*s %*s", tmproot, tmpmount, tmp_fs_type) == 3`. We could also get rid of duplicate local var `tmp_mount_point`.

test/hotspot/jtreg/containers/docker/TestCPUAwareness.java line 80:

> 78:             testCpuQuotaAndPeriod(100*1000, 100*1000, true);
> 79:             testCpuQuotaAndPeriod(150*1000, 100*1000, true);
> 80:             testCpuQuotaAndPeriod(400*1000, 100*1000, true);

It should be sufficient to test the `true` case once. I.e. one test `testCpuQuotaAndPeriod(50*1000, 100*1000, true);` should be enough (as this would extend container test runs needlessly).

test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 73:

> 71:             testMemoryLimit("500m", "524288000", true);
> 72:             testMemoryLimit("1g", "1073741824", true);
> 73:             testMemoryLimit("4g", "4294967296", true);

One test with the additional cgroup mounts should be sufficient. I suggest:


testMemoryLimit("500m", "524288000", true /* additional cgroup mount */);

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

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

From stuefe at openjdk.org  Fri Sep  9 11:45:58 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Sep 2022 11:45:58 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
Message-ID: <F3H8EFHh_tVTMXMHFLzjO3rWywFQgWyTVKpEN5zT2DU=.2c873e43-fc54-4529-91bc-0bfc35196105@github.com>

On Fri, 9 Sep 2022 08:27:41 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments in test

Looks good. Thank you for taking my suggestion!

..Thomas

> > Can you also add a test that checks that:
> > if VM is started with -Xrs, and we send a SIGQUIT, the VM shall crash with a core. The crash should look like a system crash, not an hs-err file crash, like this:
> 
> I struggled to get this to work. I found out it is due to https://bugs.openjdk.org/browse/JDK-8234262, and ProcessBuilder changes how SIGQUIT is handled in the subprocess. This is further complicated by how jtreg runs the parent process. The workaround (passing -Xrs to the parent process) does not work through jtreg using "main/othervm -Xrs".
> 
> I uploaded the not-working test in here: [caoman at 73e3a5f](https://github.com/caoman/jdk/commit/73e3a5f90985fcad9a383c704429cefb07011932)

Thank you for trying, and finding this out! I'm fine with postponing this test then to another RFE.

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

Marked as reviewed by stuefe (Reviewer).

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

From stuefe at openjdk.org  Fri Sep  9 15:23:23 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Sep 2022 15:23:23 GMT
Subject: RFR: JDK-8293313: NMT: Add "Fake OOM" mode to MallocLimit
Message-ID: <fEwDcEW1pMakKBHBdy90_KiKKcllFyZquKbvxEmxziQ=.5d663989-68ae-4e5a-bcf8-da9bdbdb6397@github.com>

This RFE adds the optional ability for `-XX:MallocLimit` to, instead of exiting the VM with a fatal error, fake a native OOM on this and all future malloc calls.

The user controls this by appending the option "oom" to the malloc limit argument:


-XX:MallocLimit=2g # will cause fatal error upon reaching limit
-XX:MallocLimit=2g,oom # will cause malloc to return NULL, mimicking a real malloc OOM


That makes it possible to test hotspot robustness in the face of real malloc OOMs, and is the prerequisite for removing the old `MallocMaxTestWords` machinery.

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

Commit messages:
 - NMT: Add "Fake OOM" mode to MallocLimit

Changes: https://git.openjdk.org/jdk/pull/10144/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10144&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293313
  Stats: 299 lines in 9 files changed: 228 ins; 38 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/10144.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10144/head:pull/10144

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

From xliu at openjdk.org  Fri Sep  9 18:07:51 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 9 Sep 2022 18:07:51 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
Message-ID: <h_4kjvPJCh08k-ojaOlOic15Ug2QNgu8ccQgaljlXoo=.1b44076a-f2a4-4861-b396-1d1706b99f65@github.com>

On Fri, 9 Sep 2022 08:27:41 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments in test

the new revision still LGTM.

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

Marked as reviewed by xliu (Committer).

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

From manc at openjdk.org  Fri Sep  9 19:16:31 2022
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Sep 2022 19:16:31 GMT
Subject: Integrated: 8292695: SIGQUIT and jcmd attaching mechanism does not
 work with signal chaining library
In-Reply-To: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
Message-ID: <rVy_mxOvxVDvWn7xN8mfU5MeudqbCW-2tNSNHyn8n9w=.868414f5-806d-43c4-8c7d-f234c52cab41@github.com>

On Sat, 20 Aug 2022 22:43:03 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
> 
> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
> 
> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
> 
> -Man

This pull request has now been integrated.

Changeset: 45ff10cc
Author:    Man Cao <manc at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45ff10cc68296c7c73d0eafe6fcc9946ab98267e
Stats:     138 lines in 4 files changed: 116 ins; 11 del; 11 mod

8292695: SIGQUIT and jcmd attaching mechanism does not work with signal chaining library

Reviewed-by: xliu, stuefe

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

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

From manc at openjdk.org  Fri Sep  9 19:24:39 2022
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Sep 2022 19:24:39 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <F3H8EFHh_tVTMXMHFLzjO3rWywFQgWyTVKpEN5zT2DU=.2c873e43-fc54-4529-91bc-0bfc35196105@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
 <F3H8EFHh_tVTMXMHFLzjO3rWywFQgWyTVKpEN5zT2DU=.2c873e43-fc54-4529-91bc-0bfc35196105@github.com>
Message-ID: <Va2K4ncrMND1JyXqUL7mpgTBnvXWiV6ylSe1NgVyi_I=.ad65f411-7f79-4c67-ba80-9fe5259bde0f@github.com>

On Fri, 9 Sep 2022 11:42:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thank you for trying, and finding this out! I'm fine with postponing this test then to another RFE.

SG. Filed https://bugs.openjdk.org/browse/JDK-8293611.

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

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

From xliu at openjdk.org  Fri Sep  9 22:26:53 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 9 Sep 2022 22:26:53 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
Message-ID: <gJoK0P7Sn6739CT35bnY1j9CRneS0oBMSjL3EI08o9I=.699f8a13-4982-43aa-ae84-de4eda88d430@github.com>

On Thu, 8 Sep 2022 10:55:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MSVC warning C4267
>>   
>>   MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
>>   'size_t' to 'int', possible loss of data
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 64:
> 
>> 62:   size_t sz = align_up(sizeof(Message) + len, sizeof(void*));
>> 63: 
>> 64:   if (_pos + sz <= _capacity || output == nullptr/*token*/) {
> 
> I don't understand this. The push token thing is not zero-sized, so what happens if we go over capacity? Or, in other words, if we fill the buffer with push tokens only, won't we overwrite and crash?

Currently, there's only one token, ie. the flushing token. We use it to implement "flushing" semantic. 

`AsyncLogWriter::flush` inserts it and is blocked until "flushing" is complete. 
Therefore, one queue can only have one token anytime. I reserve it in ctor so enqueuing of the token always succeeds. Unlike regular enqueuing, failure is not acceptable because it will hang AsyncLogWriter thread. 

Previously, I have an object called 'Token'. Since now the constructor only works for in-place new, I can't construct it on on c-heap or stack, so I use a tuple {nullptr,  AsyncLogWriter::None, ""} here.


void AsyncLogWriter::Buffer::push_flush_token() {
  bool result = push_back(nullptr, AsyncLogWriter::None, "");
  assert(result, "fail to enqueue the flush token");
}

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

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

From xliu at openjdk.org  Sat Sep 10 00:59:32 2022
From: xliu at openjdk.org (Xin Liu)
Date: Sat, 10 Sep 2022 00:59:32 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
Message-ID: <-FX_CByX2klqfi9xEBnuguNCyDEP9dUL7XQl1nZandE=.d2cb05ed-011e-442f-b498-25fd64727870@github.com>

On Thu, 8 Sep 2022 11:24:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MSVC warning C4267
>>   
>>   MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
>>   'size_t' to 'int', possible loss of data
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 89:
> 
>> 87:   // To save space and streamline execution, we just ignore null message.
>> 88:   // client should use "" instead.
>> 89:   if (msg == nullptr) return;
> 
> Is that even valid? Who logs with a NULL message? If that is valid, why treat it differently than "", and if not, why not just assert here?

make sense.  assert is better.

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

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

From stuefe at openjdk.org  Sat Sep 10 05:23:40 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Sep 2022 05:23:40 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <gJoK0P7Sn6739CT35bnY1j9CRneS0oBMSjL3EI08o9I=.699f8a13-4982-43aa-ae84-de4eda88d430@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
 <gJoK0P7Sn6739CT35bnY1j9CRneS0oBMSjL3EI08o9I=.699f8a13-4982-43aa-ae84-de4eda88d430@github.com>
Message-ID: <BZRLCiehYtD6CAoLAHHm99hkumCa45uC9-HFWGmFu84=.446a0193-f105-4786-ad5e-ec05e4e235de@github.com>

On Fri, 9 Sep 2022 22:23:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 64:
>> 
>>> 62:   size_t sz = align_up(sizeof(Message) + len, sizeof(void*));
>>> 63: 
>>> 64:   if (_pos + sz <= _capacity || output == nullptr/*token*/) {
>> 
>> I don't understand this. The push token thing is not zero-sized, so what happens if we go over capacity? Or, in other words, if we fill the buffer with push tokens only, won't we overwrite and crash?
>
> Currently, there's only one token, ie. the flushing token. We use it to implement "flushing" semantic. 
> 
> `AsyncLogWriter::flush` inserts it and is blocked until "flushing" is complete. 
> Therefore, one queue can only have one token anytime. I reserve it in ctor so enqueuing of the token always succeeds. Unlike regular enqueuing, failure is not acceptable in this case because it will hang AsyncLogWriter thread. 
> 
> Previously, I have an object called 'Token'. Since now the ctor only works for in-place new, I can't construct it on c-heap or stack anymore. I use a tuple {nullptr,  AsyncLogWriter::None, ""} instead. here is function. 
> 
> void AsyncLogWriter::Buffer::push_flush_token() {
>   bool result = push_back(nullptr, AsyncLogWriter::None, "");
>   assert(result, "fail to enqueue the flush token");
> }
> 
> 
> It's impossible to enqueue a non-token object from outside because the public interface `AsyncLogWriter::enqueue` only receives LogFileStreamOutput& as the 1st argument. There's no way to pass in null reference in C++.

Ah, I see. This is easy to miss. May I suggest a slight alteration that makes it easier to understand to the casual reader?

In Message, define a static function that calculates message byte size (the various definitions existing make me nervous, easy for them to drift apart):

    // Calculate size for a prospective Message object depending on its message length
    static constexpr size_t calc_size(int message_len) {
      return align_up(sizeof(Message) + message_len + 1, sizeof(void*));
    }


Use this in Message::size().

Get rid of TOKEN, and in the ctor, let _capacity be the real capacity. Instead, in push_back, do:


bool AsyncLogWriter::Buffer::push_back(LogFileStreamOutput* output, const LogDecorations& decorations, const char* msg) {
  const size_t sz = Message::calc_size(strlen(msg));
  const bool is_push_token = output == nullptr;
  // Always leave headroom for the push token. Pushing the push token must always succeed.
  const size_t headroom = (!is_push_token) ? Message::calc_size(0) : 0;
  if (_pos + sz <= (_capacity - headroom)) {
    new(_buf + _pos) Message(output, decorations, msg);
    _pos += sz;
    return true;
  }
  return false;
}


Now the magic is in exactly one place, and easy to understand with one glance. And we have one central place to calculate the message byte size.

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

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

From xliu at openjdk.org  Sat Sep 10 18:48:52 2022
From: xliu at openjdk.org (Xin Liu)
Date: Sat, 10 Sep 2022 18:48:52 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v5]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <Jo4WemEnYBxb6Qi0P6rRAmESvMF1ILw9eRCXKG-h08Y=.3a09c0bc-8b59-4cb6-9a27-87a30bfd3e62@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  update per reviewer's feedback.
  
  Also add a unit test for AsyncLogWriter::Buffer.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/6508429c..06a0904a

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

  Stats: 136 lines in 3 files changed: 108 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10092.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10092/head:pull/10092

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

From xliu at openjdk.org  Sun Sep 11 01:22:46 2022
From: xliu at openjdk.org (Xin Liu)
Date: Sun, 11 Sep 2022 01:22:46 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v6]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <X1YvTptCZ5he7fTtrW4KLDAGi_bhEAbnD-6e9BHzhKI=.f3adeb4a-dccc-4f14-969d-7a84aeed33e4@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  fixed for MSVC: error C2131: expression did not evaluate to a constant
  
  MSVC doesn't use C99.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/06a0904a..6b16302f

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

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

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

From xliu at openjdk.org  Sun Sep 11 20:36:40 2022
From: xliu at openjdk.org (Xin Liu)
Date: Sun, 11 Sep 2022 20:36:40 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
Message-ID: <FggfD40WfRIjhefe7LAlx6GdGsGbPUvE0bEttf4J0yc=.7ebb5937-6f4c-4c6d-af11-9e3f87222acd@github.com>

On Thu, 8 Sep 2022 11:26:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MSVC warning C4267
>>   
>>   MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
>>   'size_t' to 'int', possible loss of data
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 123:
> 
>> 121: 
>> 122:   size_t page_size = os::vm_page_size();
>> 123:   size_t size = align_up(AsyncLogBufferSize / 2, page_size);
> 
> Why page size alignment? Would also interfere with my proposal of testing with a tiny buffer.

I lift this constraint. I thought that it's was wasteful, but the functionality really doesn't depend on the page-alignment.

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

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

From xliu at openjdk.org  Sun Sep 11 21:05:44 2022
From: xliu at openjdk.org (Xin Liu)
Date: Sun, 11 Sep 2022 21:05:44 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v7]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <Vw6KZJZMJm7-SWrgOViI5qGMrmR4pcltjDvE2d4Hqks=.bb2f7067-4939-4dd5-9ee5-11406dac055b@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  add an assert for null messages.
  
  This patch changed the behehavior of Buffer. Enqueuing a null
  message is not allowed and it will trigger an assertion in debug build.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/6b16302f..7cb4398d

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

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

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

From xliu at openjdk.org  Mon Sep 12 05:40:03 2022
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 12 Sep 2022 05:40:03 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  get rid of TOKEN_SIZE.  use Message::calc_size(0) instead.
  
  it's still a compiler-time constant like TOKEN_SIZE. put the
  headroom logic in Buffer::push_back().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/7cb4398d..b2f66a8f

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

  Stats: 18 lines in 2 files changed: 7 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10092.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10092/head:pull/10092

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

From stuefe at openjdk.org  Mon Sep 12 05:58:03 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Sep 2022 05:58:03 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
In-Reply-To: <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
Message-ID: <vzDIMxqp4-lHdAWYCt9jCc7KVefNF0IPqh8eeVk-5X4=.aaa30f24-496c-4482-bb97-2c6352a8ff73@github.com>

On Mon, 12 Sep 2022 05:40:03 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of TOKEN_SIZE.  use Message::calc_size(0) instead.
>   
>   it's still a compiler-time constant like TOKEN_SIZE. put the
>   headroom logic in Buffer::push_back().

src/hotspot/share/logging/logAsyncWriter.cpp line 52:

> 50: // Reserve space for a flush token, so 'push_flush_token' always succeeds.
> 51: AsyncLogWriter::Buffer::Buffer(size_t capacity) : _pos(0), _capacity(capacity) {
> 52:   _buf = NEW_C_HEAP_ARRAY(char, capacity, mtLogging);

I would give it a low minimal size. It needs to be at least token size, but small enough to serve as a good test for simulating buffer overflows. Maybe 2-3 x header size + ~64 bytes or so. E.g. 96 bytes?

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

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

From stuefe at openjdk.org  Mon Sep 12 05:58:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Sep 2022 05:58:04 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v5]
In-Reply-To: <Jo4WemEnYBxb6Qi0P6rRAmESvMF1ILw9eRCXKG-h08Y=.3a09c0bc-8b59-4cb6-9a27-87a30bfd3e62@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jo4WemEnYBxb6Qi0P6rRAmESvMF1ILw9eRCXKG-h08Y=.3a09c0bc-8b59-4cb6-9a27-87a30bfd3e62@github.com>
Message-ID: <QigxBL5aPoxfYi7IunMIGrwB5jF6EiILKFcucgRgqkI=.370f1353-a603-4108-b9dd-97350e21ce5a@github.com>

On Sat, 10 Sep 2022 18:48:52 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update per reviewer's feedback.
>   
>   Also add a unit test for AsyncLogWriter::Buffer.

src/hotspot/share/logging/logAsyncWriter.hpp line 68:

> 66: 
> 67:   // Messsage is the envelop of a log line and its associative data.
> 68:   // The size is variety-length with zero-terminated c-str. It is only valid when we create it using placement new

s/variety/variable

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

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

From stuefe at openjdk.org  Mon Sep 12 05:58:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Sep 2022 05:58:04 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v5]
In-Reply-To: <QigxBL5aPoxfYi7IunMIGrwB5jF6EiILKFcucgRgqkI=.370f1353-a603-4108-b9dd-97350e21ce5a@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jo4WemEnYBxb6Qi0P6rRAmESvMF1ILw9eRCXKG-h08Y=.3a09c0bc-8b59-4cb6-9a27-87a30bfd3e62@github.com>
 <QigxBL5aPoxfYi7IunMIGrwB5jF6EiILKFcucgRgqkI=.370f1353-a603-4108-b9dd-97350e21ce5a@github.com>
Message-ID: <7UpT7RTfbBaUyB4wVicJ4lRHxzneGS6dKcCI7g3D61k=.b4bbf0da-ebf7-48f0-9a8a-9ba5bb65722d@github.com>

On Sun, 11 Sep 2022 05:37:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update per reviewer's feedback.
>>   
>>   Also add a unit test for AsyncLogWriter::Buffer.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 68:
> 
>> 66: 
>> 67:   // Messsage is the envelop of a log line and its associative data.
>> 68:   // The size is variety-length with zero-terminated c-str. It is only valid when we create it using placement new
> 
> s/variety/variable

Never mind, I see you changed it already

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

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

From xliu at openjdk.org  Mon Sep 12 13:41:54 2022
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 12 Sep 2022 13:41:54 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
In-Reply-To: <vzDIMxqp4-lHdAWYCt9jCc7KVefNF0IPqh8eeVk-5X4=.aaa30f24-496c-4482-bb97-2c6352a8ff73@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
 <vzDIMxqp4-lHdAWYCt9jCc7KVefNF0IPqh8eeVk-5X4=.aaa30f24-496c-4482-bb97-2c6352a8ff73@github.com>
Message-ID: <ZQL9-VPXPDFRaPWbTHYYa8_2Odqt0SH_1q99NWDKWCo=.2f574615-e13f-4991-b50e-ad9822db242e@github.com>

On Mon, 12 Sep 2022 05:55:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get rid of TOKEN_SIZE.  use Message::calc_size(0) instead.
>>   
>>   it's still a compiler-time constant like TOKEN_SIZE. put the
>>   headroom logic in Buffer::push_back().
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 52:
> 
>> 50: // Reserve space for a flush token, so 'push_flush_token' always succeeds.
>> 51: AsyncLogWriter::Buffer::Buffer(size_t capacity) : _pos(0), _capacity(capacity) {
>> 52:   _buf = NEW_C_HEAP_ARRAY(char, capacity, mtLogging);
> 
> I would give it a low minimal size. It needs to be at least token size, but small enough to serve as a good test for simulating buffer overflows. Maybe 2-3 x header size + ~64 bytes or so. E.g. 96 bytes?

HotSpot has a constraint in VMOption. The minimal number is 50K here. 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L1905

I added a unit test in test_asynclog.cpp. Like you said, I feel it's more flexible to write tests if we don't limit size here. 

If buffer capacity is smaller than a token, it will hit assertion in `Buffer::push_flush_token`.

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

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

From xliu at openjdk.org  Mon Sep 12 14:01:53 2022
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 12 Sep 2022 14:01:53 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
Message-ID: <98jWYJ6hpUZ9Si4ZhnTEFxjLV9suFPZcqoCHLh0-sEk=.a33ebf83-d4b0-4041-b44f-0e5c2c8015df@github.com>

On Thu, 8 Sep 2022 11:28:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MSVC warning C4267
>>   
>>   MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
>>   'size_t' to 'int', possible loss of data
>
> Hi Xin,
> 
> getting closer. Remarks inline.
> 
> Cheers, Thomas

hi, @tstuefe,

Thank you for reviewing this patch! I addressed most of the requests. I haven't integrated the 'len' hint yet. It's not I don't intend to. On the contrary, I found that reducing the size of 'Message' is very useful to avoid buffer overflow. I took you advice and saved the explicit c-str pointer. Another observation is that almost all `Message::_output` pointers are the same when we use just one LogOutput file. eg. one may just save all GC related activities using `-Xlog:gc*=debug,file=gc.log`. I think I can save identical pointers with `len` hint. 

Can we leave `len` optimization to the next patch? This patch just focuses on one problem: 'dynamic memory allocation'. I replaced linked-list with the pre-allocated buffer. I use NMT to validate it. It's stable with the upfront memory chunks(2*M by default):

                   Logging (reserved=2048KB, committed=2048KB)
                            (malloc=2048KB #4)

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

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

From stuefe at openjdk.org  Mon Sep 12 14:13:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Sep 2022 14:13:45 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
In-Reply-To: <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
Message-ID: <2ZG0bJRnqfU5J8dQFRt6_D43wa6TXSaPUNSyYghWbgY=.d06fce37-ef23-45d1-900d-8af135214b72@github.com>

On Mon, 12 Sep 2022 05:40:03 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of TOKEN_SIZE.  use Message::calc_size(0) instead.
>   
>   it's still a compiler-time constant like TOKEN_SIZE. put the
>   headroom logic in Buffer::push_back().

Looks good to me. Thanks for taking my suggestions. I'm fine with delaying further refinements to future RFEs.

Thanks, Thomas

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

Marked as reviewed by stuefe (Reviewer).

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

From stuefe at openjdk.org  Mon Sep 12 14:13:47 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Sep 2022 14:13:47 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
In-Reply-To: <ZQL9-VPXPDFRaPWbTHYYa8_2Odqt0SH_1q99NWDKWCo=.2f574615-e13f-4991-b50e-ad9822db242e@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
 <vzDIMxqp4-lHdAWYCt9jCc7KVefNF0IPqh8eeVk-5X4=.aaa30f24-496c-4482-bb97-2c6352a8ff73@github.com>
 <ZQL9-VPXPDFRaPWbTHYYa8_2Odqt0SH_1q99NWDKWCo=.2f574615-e13f-4991-b50e-ad9822db242e@github.com>
Message-ID: <7e8DdpE-Qgic5J6eGuhWwN3NPNeug_SxY5qSf5DSXuU=.a6532b22-7572-48db-afd5-5fc5b0251ae9@github.com>

On Mon, 12 Sep 2022 13:37:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 52:
>> 
>>> 50: // Reserve space for a flush token, so 'push_flush_token' always succeeds.
>>> 51: AsyncLogWriter::Buffer::Buffer(size_t capacity) : _pos(0), _capacity(capacity) {
>>> 52:   _buf = NEW_C_HEAP_ARRAY(char, capacity, mtLogging);
>> 
>> I would give it a low minimal size. It needs to be at least token size, but small enough to serve as a good test for simulating buffer overflows. Maybe 2-3 x header size + ~64 bytes or so. E.g. 96 bytes?
>
> HotSpot has a constraint in VMOption. The minimal number is 50K here. 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L1905
> 
> I added a unit test in test_asynclog.cpp. Like you said, I feel it's more flexible to write tests if we don't limit size here. 
> 
> If buffer capacity is smaller than a token, it will hit assertion in `Buffer::push_flush_token`.

At least add an assert then? Just to show "we know and did not forget" to the casual reader.

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

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

From xliu at openjdk.org  Mon Sep 12 14:16:28 2022
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 12 Sep 2022 14:16:28 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
Message-ID: <oag2vQNdK3tAiEIyO8vOl1m3RbZdnpSFLS9IkJLtoWY=.683ef8f2-25f0-4d8a-ab34-6d26b9383e20@github.com>

On Thu, 8 Sep 2022 11:15:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MSVC warning C4267
>>   
>>   MSVC reports logAsyncWriter.cpp(62): warning C4267: 'initializing': conversion from
>>   'size_t' to 'int', possible loss of data
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 109:
> 
>> 107:       _capacity = value;
>> 108:       return old;
>> 109:     }
> 
> Actually, I would prefer it if you did not shrink the buffer dynamically, since this is not a supported scenario and may cause unforeseen problems (besides making the code harder to argue about). 
> 
> You could just leave buffer size immutable after creation and instead add another test variation to your `AsyncLogGtest.java` where you start with a tiny tiny buffer size, and then run all your gtests with it. More test coverage, and we don't need the test coding here.
> 
> (Side note, I see that in AsyncLogGtest.java you run all tests inside a single `@test` scope. If you split them up and give them speaking id's, these tests can run in parallel. For examples, see e.g. the NMTGtests. The duplication of the test section is annoying, but the parallelization of tests you get for free is cool. Also, you can start them individually if you want to reproduce a test error.)

if we want to test 'tiny-buffer' elegantly, we have to lift the constraint of `AsyncLogBufferSize`. I just feel that we shouldn't leave a door for testing so end-user can mess with it. 

Code like this is a compromise. I think it's fine because Buffer isn't designed as a reusable component. We might be over-engineering if we try to tide up everything. What do you think?

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

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

From xliu at openjdk.org  Mon Sep 12 16:10:44 2022
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 12 Sep 2022 16:10:44 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v4]
In-Reply-To: <BZRLCiehYtD6CAoLAHHm99hkumCa45uC9-HFWGmFu84=.446a0193-f105-4786-ad5e-ec05e4e235de@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <Jupm_rmx7ILKEZy_l3bsjp5PBnuPOgG_bPwth6RPhGs=.a6699ab9-285e-478a-88a1-49ef1372fa35@github.com>
 <1CVrB7zwgCAiVDsojfBtK5x1xojTLq_h8AlgWmLRRFQ=.9c43feef-0333-4c7b-8f14-150520fc8c04@github.com>
 <gJoK0P7Sn6739CT35bnY1j9CRneS0oBMSjL3EI08o9I=.699f8a13-4982-43aa-ae84-de4eda88d430@github.com>
 <BZRLCiehYtD6CAoLAHHm99hkumCa45uC9-HFWGmFu84=.446a0193-f105-4786-ad5e-ec05e4e235de@github.com>
Message-ID: <f0Skd2LqPYxrVc9nnYBxaERXDW1WiccHpeUFqufE_9o=.22a04f59-d12d-40aa-86ee-889e6666a508@github.com>

On Sat, 10 Sep 2022 05:19:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Currently, there's only one token, ie. the flushing token. We use it to implement "flushing" semantic. 
>> 
>> `AsyncLogWriter::flush` inserts it and is blocked until "flushing" is complete. 
>> Therefore, one queue can only have one token anytime. I reserve it in ctor so enqueuing of the token always succeeds. Unlike regular enqueuing, failure is not acceptable in this case because it will hang AsyncLogWriter thread. 
>> 
>> Previously, I have an object called 'Token'. Since now the ctor only works for in-place new, I can't construct it on c-heap or stack anymore. I use a tuple {nullptr,  AsyncLogWriter::None, ""} instead. here is function. 
>> 
>> void AsyncLogWriter::Buffer::push_flush_token() {
>>   bool result = push_back(nullptr, AsyncLogWriter::None, "");
>>   assert(result, "fail to enqueue the flush token");
>> }
>> 
>> 
>> It's impossible to enqueue a non-token object from outside because the public interface `AsyncLogWriter::enqueue` only receives LogFileStreamOutput& as the 1st argument. There's no way to pass in null reference in C++.
>
> Ah, I see. This is easy to miss. May I suggest a slight alteration that makes it easier to understand to the casual reader?
> 
> In Message, define a static function that calculates message byte size (the various definitions existing make me nervous, easy for them to drift apart):
> 
>     // Calculate size for a prospective Message object depending on its message length
>     static constexpr size_t calc_size(int message_len) {
>       return align_up(sizeof(Message) + message_len + 1, sizeof(void*));
>     }
> 
> 
> Use this in Message::size().
> 
> Get rid of TOKEN, and in the ctor, let _capacity be the real capacity. Instead, in push_back, do:
> 
> 
> bool AsyncLogWriter::Buffer::push_back(LogFileStreamOutput* output, const LogDecorations& decorations, const char* msg) {
>   const size_t sz = Message::calc_size(strlen(msg));
>   const bool is_push_token = output == nullptr;
>   // Always leave headroom for the push token. Pushing the push token must always succeed.
>   const size_t headroom = (!is_push_token) ? Message::calc_size(0) : 0;
>   if (_pos + sz <= (_capacity - headroom)) {
>     new(_buf + _pos) Message(output, decorations, msg);
>     _pos += sz;
>     return true;
>   }
>   return false;
> }
> 
> 
> Now the magic is in exactly one place, and easy to understand with one glance. And we have one central place to calculate the message byte size.

update it accordingly.

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

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

From ccheung at openjdk.org  Mon Sep 12 17:17:54 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 12 Sep 2022 17:17:54 GMT
Subject: RFR: 8292225: Rename ArchiveBuilder APIs related to source and
 buffered addresses
In-Reply-To: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
References: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
Message-ID: <RNaYXtA-2z0y8o17ihLg8g6XewQtEyjuBwV3wi75P4U=.54df449d-f5af-45af-ac7b-db3262253495@github.com>

On Thu, 8 Sep 2022 06:39:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a clean up of the source code to make it more readable. 
> - When creating a CDS archive, we first load Java classes and create metadata objects as usual. These are call "source" objects.
> - We then copy the source objects into the output buffer at their "buffered addresses".
> 
> However, we used a mix of other words to refer to them:
> 
> - The word "orig" was also used for the former.
> - The words "dumped" and "relocated" were also used for the latter.
> 
> This PR renamed the names of functions and parameters to consistently use "source" and "buffered" only. In one case I reordered two fields in a class. There's otherwise no change in the code.
> 
> Please see new comments in archiveBuilder.hpp that explains the three types of addresses: "source" vs "buffered" vs "requested".

Renaming seems fine. Were there any tests run with this changset?

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

Marked as reviewed by ccheung (Reviewer).

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

From iklam at openjdk.org  Mon Sep 12 17:32:08 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 Sep 2022 17:32:08 GMT
Subject: RFR: 8292225: Rename ArchiveBuilder APIs related to source and
 buffered addresses [v2]
In-Reply-To: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
References: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
Message-ID: <SC-SI5P3t6_kYmTtYbmbehxQ9XvpL3NNpQvcv_S8sVY=.67cc188c-6d10-470c-8799-85b9556129ee@github.com>

> This is a clean up of the source code to make it more readable. 
> - When creating a CDS archive, we first load Java classes and create metadata objects as usual. These are call "source" objects.
> - We then copy the source objects into the output buffer at their "buffered addresses".
> 
> However, we used a mix of other words to refer to them:
> 
> - The word "orig" was also used for the former.
> - The words "dumped" and "relocated" were also used for the latter.
> 
> This PR renamed the names of functions and parameters to consistently use "source" and "buffered" only. In one case I reordered two fields in a class. There's otherwise no change in the code.
> 
> Please see new comments in archiveBuilder.hpp that explains the three types of addresses: "source" vs "buffered" vs "requested".

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8292225-rename-archive-builder-apis
 - 8292225: Rename ArchiveBuilder APIs related to source and buffered addresses

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10212/files
  - new: https://git.openjdk.org/jdk/pull/10212/files/dcc4ddd4..7323db4c

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

  Stats: 12385 lines in 255 files changed: 6939 ins; 4569 del; 877 mod
  Patch: https://git.openjdk.org/jdk/pull/10212.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10212/head:pull/10212

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

From ioi.lam at oracle.com  Mon Sep 12 17:52:11 2022
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 12 Sep 2022 10:52:11 -0700
Subject: [External] : Re: RFC: Change CDS JAR file validation
In-Reply-To: <CALrW1jx_Y=NRV73RKyGNgZf5cX7pfSDfYb6qQX3qj=Rc1q2KOw@mail.gmail.com>
References: <d4a49ea8-04c1-6e4d-8f2c-e5a85614b952@oracle.com>
 <CALrW1jzNJvGRg6C0ULjhjvy0DWLRxk7ba5LLALagSmX=ZAX2mg@mail.gmail.com>
 <CALrW1jx_Y=NRV73RKyGNgZf5cX7pfSDfYb6qQX3qj=Rc1q2KOw@mail.gmail.com>
Message-ID: <8ad00688-c468-267a-a06c-643771c96bc5@oracle.com>

On 9/7/2022 9:07 PM, Jiangli Zhou wrote:
> On Thu, Sep 1, 2022 at 12:51 PM Jiangli Zhou <jianglizhou at google.com> wrote:
>> When utilizing CDS for tools in a cloud environment a few years back,
>> we ran into the path checking issue. One of the main problems that we
>> observed was that the mtime based check was not reliable. Internally,
>> we've explored a few potential solutions. One of suggested ideas was
>> to compute a checksum of the jar file and store the value in the zip
>> central directory. Runtime can then validate the checksum. That can be
>> reliable. It may require specification changes.
> Some additional details about the idea using the zip central directory
> for storing checksum (which was suggested by @martin):
>
> The checksum would be computed at JAR creation time and stored in the
> zip central directory. The checksum can be updated when the JAR file
> is updated. At CDS image creation time, the JAR checksum could be
> obtained and stored in the CDS image header. Runtime can then compare
> the checksums to validate compatibility. The advantage is that it
> avoids having to compute the checksum at both CDS creation time and
> runtime. However, it requires JAR tools to be updated to support that.

Hi Jiangli,

Is there a field in the central directory for storing the creation time? 
I can't find that in the zip specification:

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

By the way, I tested all version of JDK down to JDK 6, and all of them 
would create a META-INF/ entry at the very beginning of the JAR file 
that has the creation time of the JAR file.

So I think we can effectively use the first 128 bytes of the JAR file to 
determine the creation time.

There's a catch. If the JAR file was not created using the official JAR 
file (e.g., using zip.exe), we may not have the META-INF entry.Or the 
META_INF entry may not have the actual creation time. E.g.,

 ??? zip foo.jar META-INF/MANIFEST.MF HelloWorld.class


/jdk/official$ date
Mon Sep 12 10:42:20 AM PDT 2022
/jdk/official$ for i in $(find . -name jar | sort); do echo $i; rm -f 
foo.zip; $i cf foo.jar HelloWorld.class; unzip -lv foo.jar; head -c 128 
foo.jar | hexdump -C; done
./jdk10/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 3a1538ab 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk11/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 dd089e3c 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk12/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 2f5f73c4 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk13/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 c842d553 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk14/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 1081ae75 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk15/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 f79c08e2 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk16/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 05cbe51a 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk17/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 e2d6438d 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk1.8.0_261/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 69? Defl:N?????? 68?? 1% 2022-09-12 10:42 41397d72 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 654????????????? 462? 29%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk18/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 62? Defl:N?????? 62?? 0% 2022-09-12 10:42 6f3c1517 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 647????????????? 456? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk6u_211/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 72? Defl:N?????? 72?? 0% 2022-09-12 10:42 27324655 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 657????????????? 466? 29%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 00? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 00 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk7u_321/fastdebug/bin/jar
Error occurred during initialization of VM
java/lang/ClassNotFoundException: error in opening JAR file <Zip file 
open error>
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 72? Defl:N?????? 72?? 0% 2022-09-12 10:42 27324655 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 657????????????? 466? 29%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 00? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 00 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk8_b132/linux_amd64/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 65? Defl:N?????? 64?? 2% 2022-09-12 10:42 19255984 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 650????????????? 458? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk8_b132/linux_i586/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 65? Defl:N?????? 64?? 2% 2022-09-12 10:42 19255984 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 650????????????? 458? 30%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080
./jdk9/bin/jar
Archive:? foo.jar
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?????? 0? Defl:N??????? 2?? 0% 2022-09-12 10:42 00000000 META-INF/
 ????? 61? Defl:N?????? 62? -2% 2022-09-12 10:42 3912bcee 
META-INF/MANIFEST.MF
 ???? 585? Defl:N????? 392? 33% 2022-09-12 10:39 4af91087 HelloWorld.class
--------????????? -------? ---??????????????????????????? -------
 ???? 646????????????? 456? 29%??????????????????????????? 3 files
00000000? 50 4b 03 04 14 00 08 08? 08 00 48 55 2c 55 00 00 
|PK........HU,U..|
00000010? 00 00 00 00 00 00 00 00? 00 00 09 00 04 00 4d 45 
|..............ME|
00000020? 54 41 2d 49 4e 46 2f fe? ca 00 00 03 00 50 4b 07 
|TA-INF/......PK.|
00000030? 08 00 00 00 00 02 00 00? 00 00 00 00 00 50 4b 03 
|.............PK.|
00000040? 04 14 00 08 08 08 00 48? 55 2c 55 00 00 00 00 00 
|.......HU,U.....|
00000050? 00 00 00 00 00 00 00 14? 00 00 00 4d 45 54 41 2d 
|...........META-|
00000060? 49 4e 46 2f 4d 41 4e 49? 46 45 53 54 2e 4d 46 f3 
|INF/MANIFEST.MF.|
00000070? 4d cc cb 4c 4b 2d 2e d1? 0d 4b 2d 2a ce cc cf b3 
|M..LK-...K-*....|
00000080


Thanks
- Ioi

>> Another approach is to provide a runtime flag (e.g.
>> -XX:+|-ValidateSharedClassPaths), which can be used to disable the
>> problematic jar path checking in use cases where it is safe to do so.
>> This is the approach that we have been using for tools that use CDS.
>> The tools' JAR files and CDS images are built and released together.
>> As the release progresses guarantee the compatibility between the JAR
>> file and the CDS archive in these kinds of usages, we can safely
>> disable the corresponding path checking. It also minimizes the related
>> overhead. I'd like to contribute the related patch in the short term.
> Created https://bugs.openjdk.org/browse/JDK-8293526 (apologizing for
> duplicating with https://bugs.openjdk.org/browse/JDK-8284692).
>
> Thanks,
> Jiangli
>
>> Thanks,
>> Jiangli
>>
>> On Wed, Aug 31, 2022 at 9:47 PM Ioi Lam <ioi.lam at oracle.com> wrote:
>>> Proposal Summary:
>>>
>>> Use a digest of a JAR file to detect if the file has changed
>>>
>>>
>>> Background
>>> ==========
>>>
>>> CDS is in effect a caching mechanism -- it needs to make sure that the
>>> InstanceKlasses stored in the archive are the same as those parsed from
>>> classfiles.
>>>
>>> To do this, we archive only the classes from (a) the JDK's modules image
>>> file and (b) JAR files. We don't archive classes in directories since
>>> it's difficult to check if the contents of a directory have changed.
>>>
>>> At runtime, we assume that (a) didn't change, since we require the exact
>>> same JDK build to be used.
>>>
>>> For (b) we currently do this:
>>>
>>> (1) Check that -classpath and -Xbootclasspath (absolute paths) are
>>> identical between run time and dump time.
>>> (2) For each JAR file in cp and bcp, check if its size and modification
>>> time has changed.
>>> (3) (Something similar happens with the module path ....)
>>>
>>> We have used this scheme for almost a decade. Note that we avoid reading
>>> the JAR files as that may slow down start-up time on old spinning disks.
>>> However, as most work-loads run on SSDs now, I believe this is no longer
>>> a concern.
>>>
>>> Recently, we are seeing problems when people deploy CDS inside containers:
>>>
>>> For (1) the file system structure may different between run time and
>>> dump time. We can kludge around this problem by using relative paths
>>> instead of absolute paths, but this will make the existing code even
>>> more complicated.
>>>
>>> For (2) when deploying the app, it may not be easy to keep the
>>> modification time unchanged (see JDK-8284692).
>>>
>>>
>>> Proposal
>>> ========
>>>
>>> For (1) - don't not compare directory name anymore. Only check that the
>>> filename is the same:
>>>
>>> E.g.
>>>
>>> Dump:
>>>       java -Xshare:dump -cp dir1/Foo.jar:dir2/Bar.jar ..
>>>
>>> Run:
>>>       java -cp dir1/Foo.jar:dir2/Bar.jar ...     [OK]
>>> java -cp Foo.jar:Bar.jar ...               [OK]
>>>       java -cp Foo.jar:Bxx.jar ... [Fail - changed from Bar.jar to Bxx.jar]
>>>
>>> For (2)
>>>
>>> - Check that file size has not changed.
>>> - Compute a digest of the file. Check that this has not changed.
>>>
>>>
>>> Digest
>>> ======
>>>
>>> The purpose is not for security or (malicious) tamper detection. It's
>>> for guarding against innocent mistakes (forgot to regenerate CDS archive
>>> after JAR files have been updated). Therefore, we don't need to run an
>>> expensive digest like MD5.
>>>
>>> Instead, it should be enough to just do a quick XOR digest of the first
>>> 128 bytes of the JAR file. Since this part usually contains the
>>> META-INF/ directory and its modification time. So it effectively
>>> contains the time when this JAR file was created. The timestamp seems to
>>> have a 2 second resolution:
>>>
>>> $ while true; do jar cfm foo.jar MANIFEST.MF HelloWorld.class ; head -c
>>> 128 foo.jar | cksum; sleep 2; done
>>> 3803507028 128
>>> 1857545662 128
>>> 916098721 128
>>> 3740087168 128
>>> 2260752543 128
>>> 3257546723 128
>>> 2584173820 128
>>> ...
>>>
>>>
>>> Advantage:
>>>
>>> - Make it easier to deploy CDS archive (fewer false negatives)
>>> - Simplify logic in the CDS code
>>>
>>> Risks:
>>>
>>> - Opening every JAR file may cause a slow down if you have lots of JARs
>>> in the classpath running on a slow file system.
>>>


From iklam at openjdk.org  Mon Sep 12 22:51:47 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 Sep 2022 22:51:47 GMT
Subject: RFR: 8292225: Rename ArchiveBuilder APIs related to source and
 buffered addresses [v2]
In-Reply-To: <RNaYXtA-2z0y8o17ihLg8g6XewQtEyjuBwV3wi75P4U=.54df449d-f5af-45af-ac7b-db3262253495@github.com>
References: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
 <RNaYXtA-2z0y8o17ihLg8g6XewQtEyjuBwV3wi75P4U=.54df449d-f5af-45af-ac7b-db3262253495@github.com>
Message-ID: <N5472NX9fWYMiBTsRPFHyHGrKS4UIrdjEAw0Vyp53Y8=.aeb395ff-1c99-4406-a923-c7f07111f67f@github.com>

On Mon, 12 Sep 2022 17:14:18 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Renaming seems fine. Were there any tests run with this changset?

Hi Calvin, thanks for the review. I tested with tiers 1-4 and saw no regression.

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

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

From iklam at openjdk.org  Mon Sep 12 22:57:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 Sep 2022 22:57:29 GMT
Subject: Integrated: 8292225: Rename ArchiveBuilder APIs related to source and
 buffered addresses
In-Reply-To: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
References: <9nGl3ZZlF8oYz1K7YOO5XNjYsRrb37ir71kJNxs35Y0=.80e21b4f-738d-426b-a35d-71380544934c@github.com>
Message-ID: <UGUemcyZxsoaGbNxE8Mfss2CtRyoCqrD9MoUS36w6A4=.665bdaac-2462-4ec9-8d99-cb7971ff9dc4@github.com>

On Thu, 8 Sep 2022 06:39:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a clean up of the source code to make it more readable. 
> - When creating a CDS archive, we first load Java classes and create metadata objects as usual. These are call "source" objects.
> - We then copy the source objects into the output buffer at their "buffered addresses".
> 
> However, we used a mix of other words to refer to them:
> 
> - The word "orig" was also used for the former.
> - The words "dumped" and "relocated" were also used for the latter.
> 
> This PR renamed the names of functions and parameters to consistently use "source" and "buffered" only. In one case I reordered two fields in a class. There's otherwise no change in the code.
> 
> Please see new comments in archiveBuilder.hpp that explains the three types of addresses: "source" vs "buffered" vs "requested".

This pull request has now been integrated.

Changeset: 41ce6582
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41ce6582674bb5d14f2edb34e40ee1d7ae7601d8
Stats:     115 lines in 8 files changed: 28 ins; 11 del; 76 mod

8292225: Rename ArchiveBuilder APIs related to source and buffered addresses

Reviewed-by: ccheung

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

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

From duke at openjdk.org  Tue Sep 13 02:23:04 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Tue, 13 Sep 2022 02:23:04 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v7]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <_WmZvAv5uOqGFY_5cFiTJSsJfLXHfR8OA1nQAdHJDCw=.d0d8eb58-343f-4f99-88b4-6cff159cf61a@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Simplify cg2 code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/5b73d9dd..68008b00

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

  Stats: 48 lines in 4 files changed: 0 ins; 28 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/10193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10193/head:pull/10193

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

From duke at openjdk.org  Tue Sep 13 02:23:05 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Tue, 13 Sep 2022 02:23:05 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v6]
In-Reply-To: <PreCY_JN2ObynSM9YXXIpl93Pr396srA9mWH03UFb5A=.85c553a5-78bd-4b34-a52a-6a9e476521f9@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <MNT-OYLz7OJettGEip0QHq7Y_y9gsT9oxInv-Osg5mM=.69331986-f817-40d2-b3a0-3b7a088ef8d6@github.com>
 <PreCY_JN2ObynSM9YXXIpl93Pr396srA9mWH03UFb5A=.85c553a5-78bd-4b34-a52a-6a9e476521f9@github.com>
Message-ID: <UwD6LaU0_S9RBL9oyvnkzcwaFP5Y7fC2RCdvRzcshmw=.a2dfe5f7-9673-4951-8bec-ffa6e73ee797@github.com>

On Fri, 9 Sep 2022 09:43:42 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix for cgroup v2
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 126:
> 
>> 124: }
>> 125: 
>> 126: void CgroupSubsystemFactory::set_controller_pathes(CgroupInfo* cg_infos,
> 
> Typo: `set_controller_paths`

done

> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 346:
> 
>> 344:                                    cg_infos[0]._mount_path, tmp_mount_point);
>> 345:         }
>> 346:       }
> 
> Couldn't we simplify this? For example by changing:
> 
> 
>       if (!cgroupv2_mount_point_found && strcmp("cgroup2", tmp_fs_type) == 0) {
>         cgroupv2_mount_point_found = true;
>         any_cgroup_mounts_found = true;
>         for (int i = 0; i < CG_INFO_LENGTH; i++) {
>           assert(cg_infos[i]._mount_path == NULL, "_mount_path memory stomping");
>           cg_infos[i]._mount_path = os::strdup(tmp_mount_point);
>         }
> 
> 
> to something like this:
> 
> 
>       if (strcmp("cgroup2", tmp_fs_type) == 0) {
>         cgroupv2_mount_point_found = true;
>         any_cgroup_mounts_found = true;
>         for (int i = 0; i < CG_INFO_LENGTH; i++) {
>           set_controller_paths(cg_infos, i, "(cg2, unified)", tmpmount, tmproot);
>         }
> 
> 
> It would entail modifying the `sscanf` to something like `sscanf(p, "%*d %*d %*d:%*d %s %s %*[^-]- %s %*s %*s", tmproot, tmpmount, tmp_fs_type) == 3`. We could also get rid of duplicate local var `tmp_mount_point`.

done

> test/hotspot/jtreg/containers/docker/TestCPUAwareness.java line 80:
> 
>> 78:             testCpuQuotaAndPeriod(100*1000, 100*1000, true);
>> 79:             testCpuQuotaAndPeriod(150*1000, 100*1000, true);
>> 80:             testCpuQuotaAndPeriod(400*1000, 100*1000, true);
> 
> It should be sufficient to test the `true` case once. I.e. one test `testCpuQuotaAndPeriod(50*1000, 100*1000, true);` should be enough (as this would extend container test runs needlessly).

done

> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 73:
> 
>> 71:             testMemoryLimit("500m", "524288000", true);
>> 72:             testMemoryLimit("1g", "1073741824", true);
>> 73:             testMemoryLimit("4g", "4294967296", true);
> 
> One test with the additional cgroup mounts should be sufficient. I suggest:
> 
> 
> testMemoryLimit("500m", "524288000", true /* additional cgroup mount */);

done

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

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

From duke at openjdk.org  Tue Sep 13 06:12:41 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Tue, 13 Sep 2022 06:12:41 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v8]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <pLt1TEGb-MXMMzqtX5MpkQGA5_eP5WFbA0p4aHFxtJ4=.8f9c428a-13be-4fb4-88b9-a45b8ad7d1de@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/68008b00..20cc4853

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

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

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

From xliu at openjdk.org  Tue Sep 13 06:49:59 2022
From: xliu at openjdk.org (Xin Liu)
Date: Tue, 13 Sep 2022 06:49:59 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Remove Buffer::set_capacity and make its _capacity constant.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10092/files
  - new: https://git.openjdk.org/jdk/pull/10092/files/b2f66a8f..b91794c3

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

  Stats: 47 lines in 3 files changed: 26 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10092.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10092/head:pull/10092

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

From sgehwolf at openjdk.org  Tue Sep 13 15:14:36 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 13 Sep 2022 15:14:36 GMT
Subject: RFR: JDK-8293472: Potentially incorrect container resource limit
 detection if manual cgroup fs mounts present [v8]
In-Reply-To: <pLt1TEGb-MXMMzqtX5MpkQGA5_eP5WFbA0p4aHFxtJ4=.8f9c428a-13be-4fb4-88b9-a45b8ad7d1de@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <pLt1TEGb-MXMMzqtX5MpkQGA5_eP5WFbA0p4aHFxtJ4=.8f9c428a-13be-4fb4-88b9-a45b8ad7d1de@github.com>
Message-ID: <dPbt3401xlHgJWXxUe3hgiRhVUuvsMu0VjKBCOISblI=.7b529fcd-aea0-4b98-a303-cbd0dbce21f9@github.com>

On Tue, 13 Sep 2022 06:12:41 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Looks good to me. Feel free to add the suggestion.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 304:

> 302:     //
> 303:     if (is_cgroupsV2 && sscanf(p, "%*d %*d %*d:%*d %*s %s %*[^-]- %s %*s %*s", tmp_mount_point, tmp_fs_type) == 2) {
> 304:       // we likely have an early match return (e.g. cgroup fs match), be sure we have cgroup2 as fstype

Please re-instate this comment. It's still valid and the reason why we string compare to `cgroup2`

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

Marked as reviewed by sgehwolf (Reviewer).

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

From xliu at openjdk.org  Tue Sep 13 17:03:42 2022
From: xliu at openjdk.org (Xin Liu)
Date: Tue, 13 Sep 2022 17:03:42 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
In-Reply-To: <7e8DdpE-Qgic5J6eGuhWwN3NPNeug_SxY5qSf5DSXuU=.a6532b22-7572-48db-afd5-5fc5b0251ae9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <zf-49i5knKB1t655W8J_OqEJUD4JsvAL20aVs8UQim4=.c0f52c0d-081d-471f-a82b-c7377f7069bd@github.com>
 <vzDIMxqp4-lHdAWYCt9jCc7KVefNF0IPqh8eeVk-5X4=.aaa30f24-496c-4482-bb97-2c6352a8ff73@github.com>
 <ZQL9-VPXPDFRaPWbTHYYa8_2Odqt0SH_1q99NWDKWCo=.2f574615-e13f-4991-b50e-ad9822db242e@github.com>
 <7e8DdpE-Qgic5J6eGuhWwN3NPNeug_SxY5qSf5DSXuU=.a6532b22-7572-48db-afd5-5fc5b0251ae9@github.com>
Message-ID: <Qkot3CJCIclrOYxp1ONEA-bJoAADYlNgxzjZjc4q0xo=.2c629ff0-f5cd-4531-80a2-e5a83e0e7a34@github.com>

On Mon, 12 Sep 2022 14:05:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> HotSpot has a constraint in VMOption. The minimal number is 50K here. 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L1905
>> 
>> I added a unit test in test_asynclog.cpp. Like you said, I feel it's more flexible to write tests if we don't limit size here. 
>> 
>> If buffer capacity is smaller than a token, it will hit assertion in `Buffer::push_flush_token`.
>
> At least add an assert then? Just to show "we know and did not forget" to the casual reader.

updated it!

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

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

From duke at openjdk.org  Wed Sep 14 01:17:59 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 14 Sep 2022 01:17:59 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Re-instate the comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/20cc4853..380054b4

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

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

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

From duke at openjdk.org  Wed Sep 14 01:17:59 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 14 Sep 2022 01:17:59 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <dPbt3401xlHgJWXxUe3hgiRhVUuvsMu0VjKBCOISblI=.7b529fcd-aea0-4b98-a303-cbd0dbce21f9@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <pLt1TEGb-MXMMzqtX5MpkQGA5_eP5WFbA0p4aHFxtJ4=.8f9c428a-13be-4fb4-88b9-a45b8ad7d1de@github.com>
 <dPbt3401xlHgJWXxUe3hgiRhVUuvsMu0VjKBCOISblI=.7b529fcd-aea0-4b98-a303-cbd0dbce21f9@github.com>
Message-ID: <6XaQGE8XCxk-11UbAosHcmFqtNM_KUwQRxhKgyOpG9Q=.288eef6d-0fed-4710-8551-96424008dbb8@github.com>

On Tue, 13 Sep 2022 14:36:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-instate the comment
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 304:
> 
>> 302:     //
>> 303:     if (is_cgroupsV2 && sscanf(p, "%*d %*d %*d:%*d %*s %s %*[^-]- %s %*s %*s", tmp_mount_point, tmp_fs_type) == 2) {
>> 304:       // we likely have an early match return (e.g. cgroup fs match), be sure we have cgroup2 as fstype
> 
> Please re-instate this comment. It's still valid and the reason why we string compare to `cgroup2`

Done. Thank you for your patience review.

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

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

From jiefu at openjdk.org  Wed Sep 14 03:05:11 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 14 Sep 2022 03:05:11 GMT
Subject: RFR: 8293771:
 runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if
 MEMBARRIER_CMD_QUERY is unsupported
Message-ID: <GwXlIwtXOVpDCHkiPSq6fG0nnPrtk_Y-hL5tC6nX6Zw=.f869208b-97a0-4692-ace3-7044457b185d@github.com>

Hi all,

Please review this trivial fix.
It fails due to the failing msg is incorrect in the test.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8293771: runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if MEMBARRIER_CMD_QUERY is unsupported

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

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

From rehn at openjdk.org  Wed Sep 14 07:47:47 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 14 Sep 2022 07:47:47 GMT
Subject: RFR: 8293771:
 runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if
 MEMBARRIER_CMD_QUERY is unsupported
In-Reply-To: <GwXlIwtXOVpDCHkiPSq6fG0nnPrtk_Y-hL5tC6nX6Zw=.f869208b-97a0-4692-ace3-7044457b185d@github.com>
References: <GwXlIwtXOVpDCHkiPSq6fG0nnPrtk_Y-hL5tC6nX6Zw=.f869208b-97a0-4692-ace3-7044457b185d@github.com>
Message-ID: <I2he1C7Nc-rcUQbUfAyf-VdV3l-t4B18puGAo4iUYuE=.9bd80acb-83a7-4068-94cb-91073f9a9a72@github.com>

On Wed, 14 Sep 2022 02:54:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial fix.
> It fails due to the failing msg is incorrect in the test.
> 
> Thanks.
> Best regards,
> Jie

Sorry my fault! Thanks a lot!

Looks good!

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

Marked as reviewed by rehn (Reviewer).

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

From jiefu at openjdk.org  Wed Sep 14 07:58:52 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 14 Sep 2022 07:58:52 GMT
Subject: Integrated: 8293771:
 runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if
 MEMBARRIER_CMD_QUERY is unsupported
In-Reply-To: <GwXlIwtXOVpDCHkiPSq6fG0nnPrtk_Y-hL5tC6nX6Zw=.f869208b-97a0-4692-ace3-7044457b185d@github.com>
References: <GwXlIwtXOVpDCHkiPSq6fG0nnPrtk_Y-hL5tC6nX6Zw=.f869208b-97a0-4692-ace3-7044457b185d@github.com>
Message-ID: <6CKC4aNCnWxa6uD-7bAWNCYEuOQf7S_YrQLrbrD898A=.9d7e704c-8829-4e29-9041-f6d8ba3d7438@github.com>

On Wed, 14 Sep 2022 02:54:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial fix.
> It fails due to the failing msg is incorrect in the test.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 8351b30e
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8351b30e009d5183e87277aba654cff6a6b7ab0d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8293771: runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if MEMBARRIER_CMD_QUERY is unsupported

Reviewed-by: rehn

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

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

From jiefu at openjdk.org  Wed Sep 14 07:58:50 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 14 Sep 2022 07:58:50 GMT
Subject: RFR: 8293771:
 runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if
 MEMBARRIER_CMD_QUERY is unsupported
In-Reply-To: <I2he1C7Nc-rcUQbUfAyf-VdV3l-t4B18puGAo4iUYuE=.9bd80acb-83a7-4068-94cb-91073f9a9a72@github.com>
References: <GwXlIwtXOVpDCHkiPSq6fG0nnPrtk_Y-hL5tC6nX6Zw=.f869208b-97a0-4692-ace3-7044457b185d@github.com>
 <I2he1C7Nc-rcUQbUfAyf-VdV3l-t4B18puGAo4iUYuE=.9bd80acb-83a7-4068-94cb-91073f9a9a72@github.com>
Message-ID: <X3bpXFEqTTfBS1-tGvyjDyKDbSMwZa6kAKPNGIX2DIw=.4b5e10b4-727a-4006-b6b3-5c878850cfac@github.com>

On Wed, 14 Sep 2022 07:45:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this trivial fix.
>> It fails due to the failing msg is incorrect in the test.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Sorry my fault! Thanks a lot!
> 
> Looks good!

Thanks @robehn .

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

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

From sgehwolf at openjdk.org  Wed Sep 14 08:40:53 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 14 Sep 2022 08:40:53 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
Message-ID: <-grOUzeaVyo1et6SW76WQSSNqMV0GQtHdgbRWYIZz38=.285a6022-fe30-4d40-9d98-6d9a02e98fa7@github.com>

On Wed, 14 Sep 2022 01:17:59 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-instate the comment

Marked as reviewed by sgehwolf (Reviewer).

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

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

From duke at openjdk.org  Wed Sep 14 08:52:47 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Wed, 14 Sep 2022 08:52:47 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
Message-ID: <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>

On Wed, 14 Sep 2022 01:17:59 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-instate the comment

Is it OK to be pushed? Or shall we wait for one more review?

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

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

From sgehwolf at openjdk.org  Wed Sep 14 09:14:44 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 14 Sep 2022 09:14:44 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
 <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>
Message-ID: <-hFQkZ0MdOGxdyjhH_XkHAYirdXfV3mZoPQ-0Dybeuk=.f799745d-93f8-425a-9051-6d19aff3732a@github.com>

On Wed, 14 Sep 2022 08:49:10 GMT, ?? <duke at openjdk.org> wrote:

> Is it OK to be pushed? Or shall we wait for one more review?

A second review would be good. Perhaps @iklam has some cycles?

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

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

From mbaesken at openjdk.org  Wed Sep 14 09:26:04 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 14 Sep 2022 09:26:04 GMT
Subject: RFR: JDK-8293787: Linux aarch64 build fails after 8292591
Message-ID: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>

After 8292591 we run into the following build error on Linux aarch64  (this one uses a rather old devkit):

* For target hotspot_variant-server_libjvm_objs_systemMemoryBarrier_linux.o:

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

Commit messages:
 - JDK-8293787

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

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

From aph at openjdk.org  Wed Sep 14 09:28:41 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 14 Sep 2022 09:28:41 GMT
Subject: RFR: JDK-8293787: Linux aarch64 build fails after 8292591
In-Reply-To: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
References: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
Message-ID: <DR2cg3cFnECdjtqdcj6ArGrNgpnN_1Vd7hBL8uL3CYA=.d920274e-2769-4013-aa16-e1bd8e4fd3dc@github.com>

On Wed, 14 Sep 2022 09:17:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8292591 we run into the following build error on Linux aarch64  (this one uses a rather old devkit):
> 
> * For target hotspot_variant-server_libjvm_objs_systemMemoryBarrier_linux.o:

Marked as reviewed by aph (Reviewer).

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

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

From shade at openjdk.org  Wed Sep 14 10:16:20 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Sep 2022 10:16:20 GMT
Subject: RFR: JDK-8293787: Linux aarch64 build fails after 8292591
In-Reply-To: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
References: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
Message-ID: <UtzcCue4ID9MxUYDKhLYNXyDpSj8sGzn4UgQ9KKIf2o=.efa6df5e-039c-4211-93fc-ff8321dc0f57@github.com>

On Wed, 14 Sep 2022 09:17:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8292591 we run into the following build error on Linux aarch64  (this one uses a rather old devkit):
> 
> * For target hotspot_variant-server_libjvm_objs_systemMemoryBarrier_linux.o:

Yes, this seems to match kernel definition for AArch64.

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

Marked as reviewed by shade (Reviewer).

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

From mbaesken at openjdk.org  Wed Sep 14 10:31:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 14 Sep 2022 10:31:56 GMT
Subject: Integrated: JDK-8293787: Linux aarch64 build fails after 8292591
In-Reply-To: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
References: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
Message-ID: <7gMPLBNFMuyihvWCeW2iPFhcRNQjNtNgbHErCUWe_tc=.f9202cca-8b07-40df-bf36-ee59f1dffc38@github.com>

On Wed, 14 Sep 2022 09:17:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8292591 we run into the following build error on Linux aarch64  (this one uses a rather old devkit):
> 
> * For target hotspot_variant-server_libjvm_objs_systemMemoryBarrier_linux.o:

This pull request has now been integrated.

Changeset: 7f3250d7
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f3250d71c4866a64eb73f52140c669fe90f122f
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8293787: Linux aarch64 build fails after 8292591

Reviewed-by: aph, shade

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

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

From rehn at openjdk.org  Wed Sep 14 10:45:27 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 14 Sep 2022 10:45:27 GMT
Subject: RFR: JDK-8293787: Linux aarch64 build fails after 8292591
In-Reply-To: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
References: <g4XOjxPBHzXP48YjPBSA7VJj3X14B2Jv9MCnofk-VK4=.cfd2a8fe-5696-4f49-b832-939878e35beb@github.com>
Message-ID: <byPSxGjf_Z2OmS2MxliDrq8nR6vd6Yj9Q6e_KMuwboQ=.33ea1149-f898-44d6-b0e4-433020f0746e@github.com>

On Wed, 14 Sep 2022 09:17:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8292591 we run into the following build error on Linux aarch64  (this one uses a rather old devkit):
> 
> * For target hotspot_variant-server_libjvm_objs_systemMemoryBarrier_linux.o:

Thanks!

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

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

From sgehwolf at openjdk.org  Wed Sep 14 12:34:30 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 14 Sep 2022 12:34:30 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected ressource limits with
 additional cgroup fs mounts
Message-ID: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>

Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:


test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 


I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.

Testing:
- [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
- [x] added tests fail before, pass after the product fix.
- [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
- [ ] GHA still running.

Please review! Many thanks in advance.

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

Depends on: https://git.openjdk.org/jdk/pull/10193

Commit messages:
 - 8293540: [Metrics] Potentially incorrectly detected ressource limits with additional cgroup fs mounts

Changes: https://git.openjdk.org/jdk/pull/10248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293540
  Stats: 175 lines in 6 files changed: 137 ins; 23 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

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

From stuefe at openjdk.org  Wed Sep 14 13:01:50 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 14 Sep 2022 13:01:50 GMT
Subject: RFR: JDK-8293466: libjsig should ignore non-modifying sigaction
 calls
In-Reply-To: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
References: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
Message-ID: <BvqgvZaad_WtahXb1qfMSMf3kmdiNmSCiNfKYE8cGGQ=.5172bae8-d424-45e7-b23c-1b7417347a1e@github.com>

On Sat, 10 Sep 2022 06:15:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Found during code review of [JDK-8292695](https://bugs.openjdk.org/browse/JDK-8292695).
> 
> We have two bugs in libjsig when we install hotspot signal handlers. Relevant code in libjsig:
> 
> 
> int sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {
> <snip>
> 
>   sigused = sigismember(&jvmsigs, sig);
>   if (jvm_signal_installed && sigused) {
>     /* jvm has installed its signal handler for this signal. */
>     /* Save the handler. Don't really install it. */
>     if (oact != NULL) {
>       *oact = sact[sig];
>     }
>     if (act != NULL) {
>       sact[sig] = *act;
>     }
> 
>     signal_unlock();
>     return 0;
>   } else if (jvm_signal_installing) {
>     /* jvm is installing its signal handlers. Install the new
>      * handlers and save the old ones. */
>     res = call_os_sigaction(sig, act, &oldAct);
>     sact[sig] = oldAct;
>     if (oact != NULL) {
>       *oact = oldAct;
>     }
> 
>     /* Record the signals used by jvm. */
>     sigaddset(&jvmsigs, sig);
> 
>     signal_unlock();
>     return res;
>   }
> <snip>
> }
> 
> 
> Bug 1: we change state even if the sigaction call failed
> Bug 2: we change state even if the sigaction call was a non-modifying one (act == NULL)
> 
> The latter is usually no problem since hotspot always calls `sigaction()` in pairs when installing a signal: first with NULL to get the old handler, then with the real handler. But this is not always true. If `AllowUserSignalHandlers` is set, and we find a custom handler is present, we will not override it:
> 
> 
> void set_signal_handler(int sig, bool do_check = true) {
>   // Check for overwrite.
>   struct sigaction oldAct;
>   sigaction(sig, (struct sigaction*)NULL, &oldAct); <<<<< first sigaction call, libjsig now remembers signal as set
> 
>   // Query the current signal handler. Needs to be a separate operation
>   // from installing a new handler since we need to honor AllowUserSignalHandlers.
>   void* oldhand = get_signal_handler(&oldAct);
>   if (!HANDLER_IS_IGN_OR_DFL(oldhand) &&
>       !HANDLER_IS(oldhand, javaSignalHandler)) {
>     if (AllowUserSignalHandlers) {
>       // Do not overwrite; user takes responsibility to forward to us.
>       return;
> 
> 
> That means:
> - we still have the original custom handler in place
> - but we already called sigaction, albeit with NULL, but libjsig now assumes that hotspot installed a handler itself.
> 
> The result is that any further attempts to change the signal handler, whether by hotspot or by user code, will be prevented by libjsig. Any further non-modifying sigaction calls will return the original - still installed - custom handler.
> 
> Admittedly, the error is very exotic. Users would have to set AllowUserSignalHandlers and preload libjsig, and *then* attempt to modify signal handlers after JVM initialization. But it is confusing, and a potential source for other errors. In hotspot, nobody counts on a non-modifying sigaction query changing program state somewhere.
> 
> This seems to be an old bug, I see it in at least JDK 8. Did not look further into the past
> 
> ---
> 
> Tests: Ran the runtime/jsig and the runtime/Thread tests manually.

Friendly ping.

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

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

From stuefe at openjdk.org  Wed Sep 14 13:02:02 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 14 Sep 2022 13:02:02 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
Message-ID: <_XFwCu_HCyxzpdaVZFBPQaWxbqPLM6Font8OeG-yDR8=.27ccd59a-2e85-47f1-884f-8a9b3a4b29b2@github.com>

On Wed, 7 Sep 2022 14:51:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I needed this recently. We print out the signal block mask, which is fine, but more interesting would be the existing block state at the point of the crash/assertion.

Friendly ping. Change is really simple.

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

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

From duke at openjdk.org  Wed Sep 14 13:53:48 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 14 Sep 2022 13:53:48 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
Message-ID: <Zlt9EPWTR6FZa2JJiOU4zCzz36Xg7w0FMoJ3jAzfv4g=.3fd58b26-631d-4eae-9580-8a39f8589591@github.com>

On Tue, 13 Sep 2022 06:49:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Buffer::set_capacity and make its _capacity constant.

Thank you for your efforts, this LGTM now.

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

Marked as reviewed by jdksjolen at github.com (no known OpenJDK username).

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

From alanb at openjdk.org  Wed Sep 14 13:57:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 13:57:34 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <bJQDT7GHate-wjv-FiZkeKKxE6FCoM6q_NslvsYWVoU=.3ea7d3a5-2a90-4f61-94d4-ed281409675d@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
 <bJQDT7GHate-wjv-FiZkeKKxE6FCoM6q_NslvsYWVoU=.3ea7d3a5-2a90-4f61-94d4-ed281409675d@github.com>
Message-ID: <LCNKczBZgMQYP-Ui8q9CB9Di6RZxjkh3qq7izywa0PI=.22a59de2-02cb-4cdc-b9e1-4f42fbd9839f@github.com>

On Wed, 14 Sep 2022 10:51:21 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I could reproduce the issue with `Files.createDirectories` on a macos with a trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L808. To me this appears to be something that either needs to be clarified in the the `Files.createDirectories` API or addressed/fixed there. I have asked for inputs on this from others who have more knowledge of this area.

The specification is that symbolic links are followed by default, with a few exceptions (like delete and move) where it would be wrong to follow links. Files.createDirectories was originally intended to be like mkdir -p. We'd need to check the history but I suspect it is a long standing bug that createAndCheckIsDirectory opts out of following links.

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

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

From iklam at openjdk.org  Wed Sep 14 17:01:48 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 Sep 2022 17:01:48 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
Message-ID: <-EYitBahHmoGW2XNltfAJFKtGUGCwe4Cq17MXLv9gs4=.2776502d-d570-44ee-b3c3-413bbbef5f6f@github.com>

On Wed, 14 Sep 2022 01:17:59 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-instate the comment

Looks good to me. Just a small nit on the test,

test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 94:

> 92:         DockerTestUtils.dockerRunJava(opts)
> 93:             .shouldHaveExitValue(0)
> 94:             .shouldNotContain("[os,container]");

I think it's worth commenting what you are testing for here. Maybe something like


Duplicated cgroup mounts should be handled by the container detection
code and should not cause any error/warning output.


The `[os,container]` may not match exactly. Some extra spaces may be inserted before the close bracket if longer log tags have been printed. It should be changed to 


shouldNotMatch("[os,container *]");


(Please run the test on a build without your fix to verified that it would indeed fail).

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

Marked as reviewed by iklam (Reviewer).

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

From dcubed at openjdk.org  Wed Sep 14 22:46:43 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Sep 2022 22:46:43 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected ressource limits with
 additional cgroup fs mounts
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <wE0xvQHMnxGRRaYHtjIDa33S3iHMDQLJ_cdO2Dfq53w=.bb439697-0516-4247-8bbe-80a8057b93ac@github.com>

On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

I fixed a typo in the bug's synopsis line so this PR's title needs to be update.
Doing a "/issue JDK-8293540" will do the trick.

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

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

From jianglizhou at google.com  Thu Sep 15 00:47:43 2022
From: jianglizhou at google.com (Jiangli Zhou)
Date: Wed, 14 Sep 2022 17:47:43 -0700
Subject: [External] : Re: RFC: Change CDS JAR file validation
In-Reply-To: <8ad00688-c468-267a-a06c-643771c96bc5@oracle.com>
References: <d4a49ea8-04c1-6e4d-8f2c-e5a85614b952@oracle.com>
 <CALrW1jzNJvGRg6C0ULjhjvy0DWLRxk7ba5LLALagSmX=ZAX2mg@mail.gmail.com>
 <CALrW1jx_Y=NRV73RKyGNgZf5cX7pfSDfYb6qQX3qj=Rc1q2KOw@mail.gmail.com>
 <8ad00688-c468-267a-a06c-643771c96bc5@oracle.com>
Message-ID: <CALrW1jzqCaq_ZbyNdSYDfFfaPmHD891F3_SUwVLT2-9x6A_qcw@mail.gmail.com>

On Mon, Sep 12, 2022 at 10:52 AM Ioi Lam <ioi.lam at oracle.com> wrote:

> On 9/7/2022 9:07 PM, Jiangli Zhou wrote:
> > On Thu, Sep 1, 2022 at 12:51 PM Jiangli Zhou <jianglizhou at google.com>
> wrote:
> >> When utilizing CDS for tools in a cloud environment a few years back,
> >> we ran into the path checking issue. One of the main problems that we
> >> observed was that the mtime based check was not reliable. Internally,
> >> we've explored a few potential solutions. One of suggested ideas was
> >> to compute a checksum of the jar file and store the value in the zip
> >> central directory. Runtime can then validate the checksum. That can be
> >> reliable. It may require specification changes.
> > Some additional details about the idea using the zip central directory
> > for storing checksum (which was suggested by @martin):
> >
> > The checksum would be computed at JAR creation time and stored in the
> > zip central directory. The checksum can be updated when the JAR file
> > is updated. At CDS image creation time, the JAR checksum could be
> > obtained and stored in the CDS image header. Runtime can then compare
> > the checksums to validate compatibility. The advantage is that it
> > avoids having to compute the checksum at both CDS creation time and
> > runtime. However, it requires JAR tools to be updated to support that.
>
> Hi Jiangli,
>
> Is there a field in the central directory for storing the creation time?
> I can't find that in the zip specification:
>
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT


If I recall correctly,  @martin probably suggested using the "extra field"
in a central directory header, during the brainstorming from a few years
back. That's a variable sized field. Could you please look into that? As
mentioned earlier, we didn't pursue this direction as the use cases that we
found (mostly likely are common use cases in practices) provided JAR<->JSA
compatibility at runtime. For cases that do not have such a guarantee
(possibly less common), runtime checks probably are still useful.


> By the way, I tested all version of JDK down to JDK 6, and all of them
> would create a META-INF/ entry at the very beginning of the JAR file
> that has the creation time of the JAR file.
>
> So I think we can effectively use the first 128 bytes of the JAR file to
> determine the creation time.
>

A zip file may have program code appended. Please see ZIP (file format)
<https://en.wikipedia.org/wiki/ZIP_(file_format)#:~:text=The%20ZIP%20format%20uses%20specific,byte%20central%20file%20header%20signature>
for
a brief mention. However, I guess it could always seek to the beginning of
the JAR content then check.



> There's a catch. If the JAR file was not created using the official JAR
> file (e.g., using zip.exe), we may not have the META-INF entry.Or the
> META_INF entry may not have the actual creation time. E.g.,
>

Yes. That could be fragile.

Thanks,
Jiangli


>
>      zip foo.jar META-INF/MANIFEST.MF HelloWorld.class
>
>
> /jdk/official$ date
> Mon Sep 12 10:42:20 AM PDT 2022
> /jdk/official$ for i in $(find . -name jar | sort); do echo $i; rm -f
> foo.zip; $i cf foo.jar HelloWorld.class; unzip -lv foo.jar; head -c 128
> foo.jar | hexdump -C; done
> ./jdk10/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 3a1538ab
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk11/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 dd089e3c
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk12/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 2f5f73c4
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk13/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 c842d553
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk14/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 1081ae75
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk15/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 f79c08e2
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk16/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 05cbe51a
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk17/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 e2d6438d
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk1.8.0_261/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        69  Defl:N       68   1% 2022-09-12 10:42 41397d72
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       654              462  29%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk18/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        62  Defl:N       62   0% 2022-09-12 10:42 6f3c1517
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       647              456  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk6u_211/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        72  Defl:N       72   0% 2022-09-12 10:42 27324655
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       657              466  29%                            3 files
> 00000000  50 4b 03 04 14 00 08 00  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 00 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk7u_321/fastdebug/bin/jar
> Error occurred during initialization of VM
> java/lang/ClassNotFoundException: error in opening JAR file <Zip file
> open error>
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        72  Defl:N       72   0% 2022-09-12 10:42 27324655
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       657              466  29%                            3 files
> 00000000  50 4b 03 04 14 00 08 00  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 00 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk8_b132/linux_amd64/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        65  Defl:N       64   2% 2022-09-12 10:42 19255984
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       650              458  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk8_b132/linux_i586/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        65  Defl:N       64   2% 2022-09-12 10:42 19255984
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       650              458  30%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
> ./jdk9/bin/jar
> Archive:  foo.jar
>   Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
> --------  ------  ------- ---- ---------- ----- --------  ----
>         0  Defl:N        2   0% 2022-09-12 10:42 00000000 META-INF/
>        61  Defl:N       62  -2% 2022-09-12 10:42 3912bcee
> META-INF/MANIFEST.MF
>       585  Defl:N      392  33% 2022-09-12 10:39 4af91087 HelloWorld.class
> --------          -------  ---                            -------
>       646              456  29%                            3 files
> 00000000  50 4b 03 04 14 00 08 08  08 00 48 55 2c 55 00 00
> |PK........HU,U..|
> 00000010  00 00 00 00 00 00 00 00  00 00 09 00 04 00 4d 45
> |..............ME|
> 00000020  54 41 2d 49 4e 46 2f fe  ca 00 00 03 00 50 4b 07
> |TA-INF/......PK.|
> 00000030  08 00 00 00 00 02 00 00  00 00 00 00 00 50 4b 03
> |.............PK.|
> 00000040  04 14 00 08 08 08 00 48  55 2c 55 00 00 00 00 00
> |.......HU,U.....|
> 00000050  00 00 00 00 00 00 00 14  00 00 00 4d 45 54 41 2d
> |...........META-|
> 00000060  49 4e 46 2f 4d 41 4e 49  46 45 53 54 2e 4d 46 f3
> |INF/MANIFEST.MF.|
> 00000070  4d cc cb 4c 4b 2d 2e d1  0d 4b 2d 2a ce cc cf b3
> |M..LK-...K-*....|
> 00000080
>
>
> Thanks
> - Ioi
>
> >> Another approach is to provide a runtime flag (e.g.
> >> -XX:+|-ValidateSharedClassPaths), which can be used to disable the
> >> problematic jar path checking in use cases where it is safe to do so.
> >> This is the approach that we have been using for tools that use CDS.
> >> The tools' JAR files and CDS images are built and released together.
> >> As the release progresses guarantee the compatibility between the JAR
> >> file and the CDS archive in these kinds of usages, we can safely
> >> disable the corresponding path checking. It also minimizes the related
> >> overhead. I'd like to contribute the related patch in the short term.
> > Created https://bugs.openjdk.org/browse/JDK-8293526 (apologizing for
> > duplicating with https://bugs.openjdk.org/browse/JDK-8284692).
> >
> > Thanks,
> > Jiangli
> >
> >> Thanks,
> >> Jiangli
> >>
> >> On Wed, Aug 31, 2022 at 9:47 PM Ioi Lam <ioi.lam at oracle.com> wrote:
> >>> Proposal Summary:
> >>>
> >>> Use a digest of a JAR file to detect if the file has changed
> >>>
> >>>
> >>> Background
> >>> ==========
> >>>
> >>> CDS is in effect a caching mechanism -- it needs to make sure that the
> >>> InstanceKlasses stored in the archive are the same as those parsed from
> >>> classfiles.
> >>>
> >>> To do this, we archive only the classes from (a) the JDK's modules
> image
> >>> file and (b) JAR files. We don't archive classes in directories since
> >>> it's difficult to check if the contents of a directory have changed.
> >>>
> >>> At runtime, we assume that (a) didn't change, since we require the
> exact
> >>> same JDK build to be used.
> >>>
> >>> For (b) we currently do this:
> >>>
> >>> (1) Check that -classpath and -Xbootclasspath (absolute paths) are
> >>> identical between run time and dump time.
> >>> (2) For each JAR file in cp and bcp, check if its size and modification
> >>> time has changed.
> >>> (3) (Something similar happens with the module path ....)
> >>>
> >>> We have used this scheme for almost a decade. Note that we avoid
> reading
> >>> the JAR files as that may slow down start-up time on old spinning
> disks.
> >>> However, as most work-loads run on SSDs now, I believe this is no
> longer
> >>> a concern.
> >>>
> >>> Recently, we are seeing problems when people deploy CDS inside
> containers:
> >>>
> >>> For (1) the file system structure may different between run time and
> >>> dump time. We can kludge around this problem by using relative paths
> >>> instead of absolute paths, but this will make the existing code even
> >>> more complicated.
> >>>
> >>> For (2) when deploying the app, it may not be easy to keep the
> >>> modification time unchanged (see JDK-8284692).
> >>>
> >>>
> >>> Proposal
> >>> ========
> >>>
> >>> For (1) - don't not compare directory name anymore. Only check that the
> >>> filename is the same:
> >>>
> >>> E.g.
> >>>
> >>> Dump:
> >>>       java -Xshare:dump -cp dir1/Foo.jar:dir2/Bar.jar ..
> >>>
> >>> Run:
> >>>       java -cp dir1/Foo.jar:dir2/Bar.jar ...     [OK]
> >>> java -cp Foo.jar:Bar.jar ...               [OK]
> >>>       java -cp Foo.jar:Bxx.jar ... [Fail - changed from Bar.jar to
> Bxx.jar]
> >>>
> >>> For (2)
> >>>
> >>> - Check that file size has not changed.
> >>> - Compute a digest of the file. Check that this has not changed.
> >>>
> >>>
> >>> Digest
> >>> ======
> >>>
> >>> The purpose is not for security or (malicious) tamper detection. It's
> >>> for guarding against innocent mistakes (forgot to regenerate CDS
> archive
> >>> after JAR files have been updated). Therefore, we don't need to run an
> >>> expensive digest like MD5.
> >>>
> >>> Instead, it should be enough to just do a quick XOR digest of the first
> >>> 128 bytes of the JAR file. Since this part usually contains the
> >>> META-INF/ directory and its modification time. So it effectively
> >>> contains the time when this JAR file was created. The timestamp seems
> to
> >>> have a 2 second resolution:
> >>>
> >>> $ while true; do jar cfm foo.jar MANIFEST.MF HelloWorld.class ; head -c
> >>> 128 foo.jar | cksum; sleep 2; done
> >>> 3803507028 <(380)%20350-7028> 128
> >>> 1857545662 128
> >>> 916098721 128
> >>> 3740087168 128
> >>> 2260752543 128
> >>> 3257546723 <(325)%20754-6723> 128
> >>> 2584173820 128
> >>> ...
> >>>
> >>>
> >>> Advantage:
> >>>
> >>> - Make it easier to deploy CDS archive (fewer false negatives)
> >>> - Simplify logic in the CDS code
> >>>
> >>> Risks:
> >>>
> >>> - Opening every JAR file may cause a slow down if you have lots of JARs
> >>> in the classpath running on a slow file system.
> >>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20220914/d4c98961/attachment-0001.htm>

From duke at openjdk.org  Thu Sep 15 03:03:42 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 03:03:42 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v10]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <lZqYitlh1Vp-iivZGyVuK4cwZ1fyDx3OKvQgg-ChvgE=.b7176100-8061-4503-9d92-30733d794a14@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/380054b4..68507d02

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

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

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

From duke at openjdk.org  Thu Sep 15 03:03:45 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 03:03:45 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <-EYitBahHmoGW2XNltfAJFKtGUGCwe4Cq17MXLv9gs4=.2776502d-d570-44ee-b3c3-413bbbef5f6f@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
 <-EYitBahHmoGW2XNltfAJFKtGUGCwe4Cq17MXLv9gs4=.2776502d-d570-44ee-b3c3-413bbbef5f6f@github.com>
Message-ID: <BZ59CYCJXUklfmg8ww07pKGfs1mZHtCEs2FpuY5Vo9Y=.06f1cdb3-ee2f-4fe4-b744-687c58f270b3@github.com>

On Wed, 14 Sep 2022 16:57:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-instate the comment
>
> test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 94:
> 
>> 92:         DockerTestUtils.dockerRunJava(opts)
>> 93:             .shouldHaveExitValue(0)
>> 94:             .shouldNotContain("[os,container]");
> 
> I think it's worth commenting what you are testing for here. Maybe something like
> 
> 
> Duplicated cgroup mounts should be handled by the container detection
> code and should not cause any error/warning output.
> 
> 
> The `[os,container]` may not match exactly. Some extra spaces may be inserted before the close bracket if longer log tags have been printed. It should be changed to 
> 
> 
> shouldNotMatch("[os,container *]");
> 
> 
> (Please run the test on a build without your fix to verified that it would indeed fail).

Thank you for the review suggestions.

The comment has been added. When turn on `-Xlog:os+container=trace `, the output is like the following

[0.000s][trace][os,container] OSContainer::init: Initializing Container Support
[0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.000s][debug][os,container] Duplicate pids controllers detected. Picking /sys/fs/cgroup/pids, skipping /cgroups-in/pids.
[0.000s][debug][os,container] Duplicate cpuset controllers detected. Picking /sys/fs/cgroup/cpuset, skipping /cgroups-in/cpuset.
[0.000s][debug][os,container] Duplicate cpu controllers detected. Picking /sys/fs/cgroup/cpu,cpuacct, skipping /cgroups-in/cpu,cpuacct.
[0.001s][debug][os,container] Duplicate cpuacct controllers detected. Picking /sys/fs/cgroup/cpu,cpuacct, skipping /cgroups-in/cpu,cpuacct.
[0.001s][debug][os,container] Duplicate memory controllers detected. Picking /sys/fs/cgroup/memory, skipping /cgroups-in/memory.
[0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.001s][trace][os,container] Path to /memory.use_hierarchy is /sys/fs/cgroup/memory/memory.use_hierarchy
[0.001s][trace][os,container] Use Hierarchy is: 1
[0.001s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
[0.001s][trace][os,container] CPU Quota is: -1
[0.001s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
[0.001s][trace][os,container] CPU Period is: 100000
[0.001s][trace][os,container] OSContainer::active_processor_count: 16
[0.001s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 16
[0.001s][trace][os,container] total physical memory: 33396502528
[0.001s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
[0.001s][trace][os,container] Memory Limit is: 9223372036854771712
[0.001s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited
[0.001s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat
[0.001s][trace][os,container] Hierarchical Memory Limit is: 9223372036854771712
[0.001s][trace][os,container] Hierarchical Memory Limit is: Unlimited
[0.001s][debug][os,container] container memory limit unlimited: -1, using host value 33396502528
[0.003s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 16
[0.045s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
[0.045s][trace][os,container] CPU Quota is: -1
[0.045s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
[0.045s][trace][os,container] CPU Period is: 100000
[0.045s][trace][os,container] OSContainer::active_processor_count: 16
[0.052s][trace][os,container] total physical memory: 33396502528
[0.052s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
[0.052s][trace][os,container] Memory Limit is: 9223372036854771712
[0.052s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited
[0.052s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat
[0.052s][trace][os,container] Hierarchical Memory Limit is: 9223372036854771712
[0.052s][trace][os,container] Hierarchical Memory Limit is: Unlimited
[0.052s][debug][os,container] container memory limit unlimited: -1, using host value 33396502528


so `"[os,container *]"` will not match the output, and add an extra `*` will make failed test pass.

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

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

From iklam at openjdk.org  Thu Sep 15 03:38:44 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 Sep 2022 03:38:44 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <BZ59CYCJXUklfmg8ww07pKGfs1mZHtCEs2FpuY5Vo9Y=.06f1cdb3-ee2f-4fe4-b744-687c58f270b3@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
 <-EYitBahHmoGW2XNltfAJFKtGUGCwe4Cq17MXLv9gs4=.2776502d-d570-44ee-b3c3-413bbbef5f6f@github.com>
 <BZ59CYCJXUklfmg8ww07pKGfs1mZHtCEs2FpuY5Vo9Y=.06f1cdb3-ee2f-4fe4-b744-687c58f270b3@github.com>
Message-ID: <kSYJqBBo2q9tF0MWeEDbRhYJhvNhdRYeDp3tCPBgoT4=.3b84ef49-5cdb-4c07-a276-713c72263f87@github.com>

On Thu, 15 Sep 2022 02:58:41 GMT, ?? <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/containers/docker/DockerBasicTest.java line 94:
>> 
>>> 92:         DockerTestUtils.dockerRunJava(opts)
>>> 93:             .shouldHaveExitValue(0)
>>> 94:             .shouldNotContain("[os,container]");
>> 
>> I think it's worth commenting what you are testing for here. Maybe something like
>> 
>> 
>> Duplicated cgroup mounts should be handled by the container detection
>> code and should not cause any error/warning output.
>> 
>> 
>> The `[os,container]` may not match exactly. Some extra spaces may be inserted before the close bracket if longer log tags have been printed. It should be changed to 
>> 
>> 
>> shouldNotMatch("[os,container *]");
>> 
>> 
>> (Please run the test on a build without your fix to verified that it would indeed fail).
>
> Thank you for the review suggestions.
> 
> The comment has been added. When turn on `-Xlog:os+container=trace `, the output is like the following
> 
> [0.000s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.000s][debug][os,container] Duplicate pids controllers detected. Picking /sys/fs/cgroup/pids, skipping /cgroups-in/pids.
> [0.000s][debug][os,container] Duplicate cpuset controllers detected. Picking /sys/fs/cgroup/cpuset, skipping /cgroups-in/cpuset.
> [0.000s][debug][os,container] Duplicate cpu controllers detected. Picking /sys/fs/cgroup/cpu,cpuacct, skipping /cgroups-in/cpu,cpuacct.
> [0.001s][debug][os,container] Duplicate cpuacct controllers detected. Picking /sys/fs/cgroup/cpu,cpuacct, skipping /cgroups-in/cpu,cpuacct.
> [0.001s][debug][os,container] Duplicate memory controllers detected. Picking /sys/fs/cgroup/memory, skipping /cgroups-in/memory.
> [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.001s][trace][os,container] Path to /memory.use_hierarchy is /sys/fs/cgroup/memory/memory.use_hierarchy
> [0.001s][trace][os,container] Use Hierarchy is: 1
> [0.001s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
> [0.001s][trace][os,container] CPU Quota is: -1
> [0.001s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
> [0.001s][trace][os,container] CPU Period is: 100000
> [0.001s][trace][os,container] OSContainer::active_processor_count: 16
> [0.001s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 16
> [0.001s][trace][os,container] total physical memory: 33396502528
> [0.001s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
> [0.001s][trace][os,container] Memory Limit is: 9223372036854771712
> [0.001s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited
> [0.001s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat
> [0.001s][trace][os,container] Hierarchical Memory Limit is: 9223372036854771712
> [0.001s][trace][os,container] Hierarchical Memory Limit is: Unlimited
> [0.001s][debug][os,container] container memory limit unlimited: -1, using host value 33396502528
> [0.003s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 16
> [0.045s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
> [0.045s][trace][os,container] CPU Quota is: -1
> [0.045s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
> [0.045s][trace][os,container] CPU Period is: 100000
> [0.045s][trace][os,container] OSContainer::active_processor_count: 16
> [0.052s][trace][os,container] total physical memory: 33396502528
> [0.052s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
> [0.052s][trace][os,container] Memory Limit is: 9223372036854771712
> [0.052s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited
> [0.052s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat
> [0.052s][trace][os,container] Hierarchical Memory Limit is: 9223372036854771712
> [0.052s][trace][os,container] Hierarchical Memory Limit is: Unlimited
> [0.052s][debug][os,container] container memory limit unlimited: -1, using host value 33396502528
> 
> 
> so `"[os,container *]"` will not match the output, and add an extra `*` will make failed test pass.

I am sorry, I meant to use a regular expression to account for any possible space characters that comes after the `os,container`. Example:


$ java -Xlog:all -Xlog:os+container=debug --version | grep -i container | tail -2
[0.033s][debug][os,container   ] container memory limit unlimited: -1, using host value
[0.033s][debug][os,container   ] container memory limit unlimited: -1, using host value


Instead of `shouldNotContain`, which takes a plain string, you should use `shouldNotMatch`, which takes a regular expression:


.shouldNotMatch("[os,container *]");

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

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

From duke at openjdk.org  Thu Sep 15 05:01:45 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 05:01:45 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v11]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <_sYoDYK3SHpY9g-IhIrDzt_Oko3CtZ9P6mMhYey5XUw=.f7799cbe-e53a-4bd8-a1f1-213100a7675f@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Use shouldNotMatch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/68507d02..9bc1f325

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=09-10

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

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

From duke at openjdk.org  Thu Sep 15 05:17:04 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 05:17:04 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v12]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <Iz7sipQpc0_sQBsaeMbTHYmN-uq_g0i-m2q_lfXhMxo=.b850c579-4788-433b-9898-5921057459a4@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Use regular exp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/9bc1f325..c4109d65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=10-11

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

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

From duke at openjdk.org  Thu Sep 15 05:17:04 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 05:17:04 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <kSYJqBBo2q9tF0MWeEDbRhYJhvNhdRYeDp3tCPBgoT4=.3b84ef49-5cdb-4c07-a276-713c72263f87@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
 <-EYitBahHmoGW2XNltfAJFKtGUGCwe4Cq17MXLv9gs4=.2776502d-d570-44ee-b3c3-413bbbef5f6f@github.com>
 <BZ59CYCJXUklfmg8ww07pKGfs1mZHtCEs2FpuY5Vo9Y=.06f1cdb3-ee2f-4fe4-b744-687c58f270b3@github.com>
 <kSYJqBBo2q9tF0MWeEDbRhYJhvNhdRYeDp3tCPBgoT4=.3b84ef49-5cdb-4c07-a276-713c72263f87@github.com>
Message-ID: <yGXUxXPJzvPFhOtz5ouGay4xxePb1Bt0Gk3FjlQSOqs=.3290fef3-f10f-4122-9eff-fb2fa0d0dc54@github.com>

On Thu, 15 Sep 2022 03:35:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thank you for the review suggestions.
>> 
>> The comment has been added. When turn on `-Xlog:os+container=trace `, the output is like the following
>> 
>> [0.000s][trace][os,container] OSContainer::init: Initializing Container Support
>> [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
>> [0.000s][debug][os,container] Duplicate pids controllers detected. Picking /sys/fs/cgroup/pids, skipping /cgroups-in/pids.
>> [0.000s][debug][os,container] Duplicate cpuset controllers detected. Picking /sys/fs/cgroup/cpuset, skipping /cgroups-in/cpuset.
>> [0.000s][debug][os,container] Duplicate cpu controllers detected. Picking /sys/fs/cgroup/cpu,cpuacct, skipping /cgroups-in/cpu,cpuacct.
>> [0.001s][debug][os,container] Duplicate cpuacct controllers detected. Picking /sys/fs/cgroup/cpu,cpuacct, skipping /cgroups-in/cpu,cpuacct.
>> [0.001s][debug][os,container] Duplicate memory controllers detected. Picking /sys/fs/cgroup/memory, skipping /cgroups-in/memory.
>> [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
>> [0.001s][trace][os,container] Path to /memory.use_hierarchy is /sys/fs/cgroup/memory/memory.use_hierarchy
>> [0.001s][trace][os,container] Use Hierarchy is: 1
>> [0.001s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
>> [0.001s][trace][os,container] CPU Quota is: -1
>> [0.001s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
>> [0.001s][trace][os,container] CPU Period is: 100000
>> [0.001s][trace][os,container] OSContainer::active_processor_count: 16
>> [0.001s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 16
>> [0.001s][trace][os,container] total physical memory: 33396502528
>> [0.001s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
>> [0.001s][trace][os,container] Memory Limit is: 9223372036854771712
>> [0.001s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited
>> [0.001s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat
>> [0.001s][trace][os,container] Hierarchical Memory Limit is: 9223372036854771712
>> [0.001s][trace][os,container] Hierarchical Memory Limit is: Unlimited
>> [0.001s][debug][os,container] container memory limit unlimited: -1, using host value 33396502528
>> [0.003s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 16
>> [0.045s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
>> [0.045s][trace][os,container] CPU Quota is: -1
>> [0.045s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
>> [0.045s][trace][os,container] CPU Period is: 100000
>> [0.045s][trace][os,container] OSContainer::active_processor_count: 16
>> [0.052s][trace][os,container] total physical memory: 33396502528
>> [0.052s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
>> [0.052s][trace][os,container] Memory Limit is: 9223372036854771712
>> [0.052s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited
>> [0.052s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat
>> [0.052s][trace][os,container] Hierarchical Memory Limit is: 9223372036854771712
>> [0.052s][trace][os,container] Hierarchical Memory Limit is: Unlimited
>> [0.052s][debug][os,container] container memory limit unlimited: -1, using host value 33396502528
>> 
>> 
>> so `"[os,container *]"` will not match the output, and add an extra `*` will make failed test pass.
>
> I am sorry, I meant to use a regular expression to account for any possible space characters that comes after the `os,container`. Example:
> 
> 
> $ java -Xlog:all -Xlog:os+container=debug --version | grep -i container | tail -2
> [0.033s][debug][os,container   ] container memory limit unlimited: -1, using host value
> [0.033s][debug][os,container   ] container memory limit unlimited: -1, using host value
> 
> 
> Instead of `shouldNotContain`, which takes a plain string, you should use `shouldNotMatch`, which takes a regular expression:
> 
> 
> .shouldNotMatch("[os,container *]");

Thanks for the suggestion, I have changed it to regular expression `.shouldNotMatch("\[os,container *\]");`

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

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

From iklam at openjdk.org  Thu Sep 15 05:24:03 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 Sep 2022 05:24:03 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v12]
In-Reply-To: <Iz7sipQpc0_sQBsaeMbTHYmN-uq_g0i-m2q_lfXhMxo=.b850c579-4788-433b-9898-5921057459a4@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <Iz7sipQpc0_sQBsaeMbTHYmN-uq_g0i-m2q_lfXhMxo=.b850c579-4788-433b-9898-5921057459a4@github.com>
Message-ID: <ZBLP0ZSSDgseD5n5XkuplO9rYZn-JqVbLb_2pGPuTVg=.34484d86-10e6-4056-b6a3-15fc81ab51c4@github.com>

On Thu, 15 Sep 2022 05:17:04 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use regular exp

Marked as reviewed by iklam (Reviewer).

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

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

From stuefe at openjdk.org  Thu Sep 15 05:35:44 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Sep 2022 05:35:44 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <Zlt9EPWTR6FZa2JJiOU4zCzz36Xg7w0FMoJ3jAzfv4g=.3fd58b26-631d-4eae-9580-8a39f8589591@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
 <Zlt9EPWTR6FZa2JJiOU4zCzz36Xg7w0FMoJ3jAzfv4g=.3fd58b26-631d-4eae-9580-8a39f8589591@github.com>
Message-ID: <8RvTrL5rcgeAkqyo3f7vmCtzZKkdy2ykD1N6Nt3MTTg=.c55ee44a-3855-41ea-b09d-c7e779270881@github.com>

On Wed, 14 Sep 2022 13:50:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>Thank you for your efforts, this LGTM now.

>@jdksjolen (no known github.com user name / role)

>I've forgotten to associate my OpenJDK account with my Github account, so my approval counts for nothing at the moment :-(.

IIRC, in hotspot we need two reviews, one Reviewer, the other at least Contributor. Maybe one of your team should propose you as Contributor (@coleenp?), then your reviews count too. I think you have the required number of patches already.

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

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

From duke at openjdk.org  Thu Sep 15 05:59:03 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 05:59:03 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v13]
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <FF7Y64lEyvZYgyW2m49sIn-dmmBL5N9MLgWWE6EDhKM=.bcef62db-bf0b-459b-874e-bd78d449cb10@github.com>

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10193/files
  - new: https://git.openjdk.org/jdk/pull/10193/files/c4109d65..8170214f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10193&range=11-12

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

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

From rrich at openjdk.org  Thu Sep 15 07:30:44 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 15 Sep 2022 07:30:44 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v2]
In-Reply-To: <5olJdPTm_wQCxU59VeZgTRMp6SW_IeFwtSydqhuvWrg=.681e6127-9e5b-4507-9579-ad9c818a1a84@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <Acek4VP0QVB5ob6sZuriqXPMyjH8IuNEifspUU7kV78=.e17d8389-cbcc-493c-b1e0-9b16fe591fb3@github.com>
 <-bsqwA9AOikvIYJwIgJ7ms1RaF_OqH-UO3juTGZ-Zzc=.6dc5abda-60a3-4f76-83df-6afab3f3a1db@github.com>
 <5olJdPTm_wQCxU59VeZgTRMp6SW_IeFwtSydqhuvWrg=.681e6127-9e5b-4507-9579-ad9c818a1a84@github.com>
Message-ID: <YFyVovhmRFrWEFbGtbojH-qW_7g3CEECia77RFySOcc=.6f9456c0-72b9-468c-a298-d3cab5fc29ec@github.com>

On Fri, 26 Aug 2022 08:10:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> > The interpreter allocates a new frame reserving space for the maximum expression stack. For a call it is trimmed to the current size of the stack. Consequently unextended_sp < sp is possible if max. stack is large.
> 
> OK, if I'm not mistaken, aarch64 is doing the same thing.

I have had a look at aarch64 now. There the interpreter also pushes a new frame
reserving space for the maximum expression stack as on ppc64 but the frame is
_not_ trimmed to the current size of the expression stack as on ppc64. So on
aarch64 unextended_sp < sp seems to be impossible.

> So that could mean that code like Continuation::is_frame_in_continuation()
> that uses unextended_sp is already broken on some platforms. For example, if
> an interpreted frame in the carrier thread had a very large max_stack, then
> is_frame_in_continuation() could return true when it should return false.

It is likely not yet broken but for ppc64 it will not work. The usage of
unextended_sp in shared code is problematic because there is no shared
specification for it.

Looking at the callers of is_sp_in_continuation() we find the the following is passed as parameter `sp`:

1. frame::interpreter_frame_last_sp()
2. frame::unextended_sp()
3. frame::sp() - 2
4. frame::sp()

Where 3. is a special case for continuation entry frames (see
Continuation::get_continuation_entry_for_entry_frame()). -2 is needed because
is_sp_in_continuation() would return false for the sp of the entry frame.

I'd like to change the callers of is_sp_in_continuation()

```c++
static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
  return entry->entry_sp() > sp;
}


to pass the actual sp. This is correct because the following is true on all
platforms:

```c++
a.sp() > E->entry_sp() > b.sp() > c.sp()


where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry.
`a` is the caller frame of the continuation entry frame that corresponds to `E`.

is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and
false for `a.sp()`. At least on ppc64 is_sp_in_continuation() can return true
for `a.unextended_sp()` because of the frame trimming described above. That's
why it should not be used. frame::interpreter_frame_last_sp() should not be used
as it is not declared and specified as a shared method.

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

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

From rrich at openjdk.org  Thu Sep 15 07:43:23 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 15 Sep 2022 07:43:23 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v3]
In-Reply-To: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
Message-ID: <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>

> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
> 
> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
> 
> This fix simply removes the special case for interpreted frames in the shared method `Continuation::continuation_bottom_sender()`. I cannot see a reason for the distinction between interpreted and compiled frames. The shared code reference to `frame::interpreter_frame_last_sp()` is thereby eliminated.
> 
> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.

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

 - Only pass the actual sp when calling is_sp_in_continuation()
 - Merge branch 'master'
 - Merge branch 'master'
 - Remove platform dependent method interpreter_frame_last_sp() from shared code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9411/files
  - new: https://git.openjdk.org/jdk/pull/9411/files/c3ad382c..fdb14090

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

  Stats: 163416 lines in 2548 files changed: 79922 ins; 68601 del; 14893 mod
  Patch: https://git.openjdk.org/jdk/pull/9411.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9411/head:pull/9411

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

From rrich at openjdk.org  Thu Sep 15 07:49:38 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 15 Sep 2022 07:49:38 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v3]
In-Reply-To: <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>
Message-ID: <3TRqlNrdNKvq5h70pg133Z3Fc2FNcTGccRZP7fYThMw=.89808b99-40c6-4dc4-9186-d3750b062636@github.com>

On Thu, 15 Sep 2022 07:43:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> This fix simply removes the special case for interpreted frames in the shared method `Continuation::continuation_bottom_sender()`. I cannot see a reason for the distinction between interpreted and compiled frames. The shared code reference to `frame::interpreter_frame_last_sp()` is thereby eliminated.
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Only pass the actual sp when calling is_sp_in_continuation()
>  - Merge branch 'master'
>  - Merge branch 'master'
>  - Remove platform dependent method interpreter_frame_last_sp() from shared code

hotspot_loom and jdk_loom tests on x86_64 and aarch64 still pass with the last commit https://github.com/openjdk/jdk/pull/9411/commits/fdb14090e74e8adb9046c10065f03e4e46e09f1c.
Tests with the ppc64 loom port succeeded as well.

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

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

From sgehwolf at openjdk.org  Thu Sep 15 08:07:08 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:07:08 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <4fY8V3tuDctSf_kqS2pDNuIKKlJMVNPllkm753EwmTc=.5519d859-57b2-4493-9d5e-7e7311538d12@github.com>

On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

Thanks! I've updated the PR title to match the bug synopsis.

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

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

From sgehwolf at openjdk.org  Thu Sep 15 08:11:49 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:11:49 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v13]
In-Reply-To: <FF7Y64lEyvZYgyW2m49sIn-dmmBL5N9MLgWWE6EDhKM=.bcef62db-bf0b-459b-874e-bd78d449cb10@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <FF7Y64lEyvZYgyW2m49sIn-dmmBL5N9MLgWWE6EDhKM=.bcef62db-bf0b-459b-874e-bd78d449cb10@github.com>
Message-ID: <48IVCErFFrt3vYWs326nZpcE69P4cdpWsFXPAcH-AIY=.b448a783-88bb-413b-b09e-6256fd8a6ce3@github.com>

On Thu, 15 Sep 2022 05:59:03 GMT, ?? <duke at openjdk.org> wrote:

>> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Still good for me.

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

Marked as reviewed by sgehwolf (Reviewer).

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

From sgehwolf at openjdk.org  Thu Sep 15 08:14:37 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:14:37 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
 <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>
Message-ID: <fBmk-DMXnMwoPWGvKBLQ7Im9aAKwY4uClSuSuBnp1tk=.bb2c9759-dc91-4919-99a5-5154a9cd385f@github.com>

On Wed, 14 Sep 2022 08:49:10 GMT, ?? <duke at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-instate the comment
>
> Is it OK to be pushed? Or shall we wait for one more review?

@casparcwang Feel free to issue `/integrate` again and I'll sponsor. Thanks!

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

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

From duke at openjdk.org  Thu Sep 15 08:46:03 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 08:46:03 GMT
Subject: RFR: JDK-8293472: Incorrect container resource limit detection if
 manual cgroup fs mounts present [v9]
In-Reply-To: <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
 <C_5ye82veojWhTqfhgTMV8Y6dy4uGVbiEfXvzfTEUas=.78ce933e-ad0f-4c5e-a478-8be431f0b13f@github.com>
 <jig36Iv1vS-V1RjFgbChzK3V67mvh4MDTzDfYCny8VQ=.52624b1f-fd44-4f76-8ff2-af75bc37e615@github.com>
Message-ID: <Wwl9brd2XB3vtF1mCPAmJuYYsRkFCPIxWKCubWka7Cs=.21bd61aa-940c-4ad7-8092-1f6801bcbb85@github.com>

On Wed, 14 Sep 2022 08:49:10 GMT, ?? <duke at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-instate the comment
>
> Is it OK to be pushed? Or shall we wait for one more review?

> @casparcwang Feel free to issue `/integrate` again and I'll sponsor. Thanks!

Thank you very much!

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

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

From duke at openjdk.org  Thu Sep 15 08:50:19 2022
From: duke at openjdk.org (=?UTF-8?B?546L6LaF?=)
Date: Thu, 15 Sep 2022 08:50:19 GMT
Subject: Integrated: JDK-8293472: Incorrect container resource limit detection
 if manual cgroup fs mounts present
In-Reply-To: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
References: <QfvMsTy1CAdOLkmvLp38l7dixK8RZq30u_vKeHY0bWg=.fd32ccd9-c89b-40c7-b846-d96f9082f090@github.com>
Message-ID: <usOHUuv5mIdtb6f42qXjvj9-bQ54lsXDZmKOvwS38VQ=.7e020ce4-d251-4a7f-8957-ce7923187968@github.com>

On Wed, 7 Sep 2022 08:35:47 GMT, ?? <duke at openjdk.org> wrote:

> Similar to [JDK-8253435](https://bugs.openjdk.org/browse/JDK-8253435), when setting the mount path of cgroup controller "memory/cpu/cpuacct/pids", it should also discard duplicate items.

This pull request has now been integrated.

Changeset: 8f3bbe95
Author:    casparcwang <casparcwang at tencent.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f3bbe950fb5a3d9f6cae122209df01df0f342f0
Stats:     162 lines in 6 files changed: 108 ins; 27 del; 27 mod

8293472: Incorrect container resource limit detection if manual cgroup fs mounts present

Reviewed-by: sgehwolf, iklam

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

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

From sgehwolf at openjdk.org  Thu Sep 15 08:51:55 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:51:55 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v2]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <wwto6_qZN_7QJNXaswOYSs3dMkUjghbly4PzFXtwfIc=.1dc331ba-8633-4ae2-9d3d-ffe5110a86a3@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

Severin Gehwolf 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10248/files
  - new: https://git.openjdk.org/jdk/pull/10248/files/9cc6c7cd..9cc6c7cd

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

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

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

From sgehwolf at openjdk.org  Thu Sep 15 08:55:41 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:55:41 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

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

  8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

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

Changes: https://git.openjdk.org/jdk/pull/10248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02
  Stats: 175 lines in 6 files changed: 137 ins; 23 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

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

From jsjolen at openjdk.org  Thu Sep 15 08:57:06 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 15 Sep 2022 08:57:06 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <8RvTrL5rcgeAkqyo3f7vmCtzZKkdy2ykD1N6Nt3MTTg=.c55ee44a-3855-41ea-b09d-c7e779270881@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
 <Zlt9EPWTR6FZa2JJiOU4zCzz36Xg7w0FMoJ3jAzfv4g=.3fd58b26-631d-4eae-9580-8a39f8589591@github.com>
 <8RvTrL5rcgeAkqyo3f7vmCtzZKkdy2ykD1N6Nt3MTTg=.c55ee44a-3855-41ea-b09d-c7e779270881@github.com>
Message-ID: <09ODl20Suqt8tuQw2Am5ojoB5SO9qtTCIJqUwjeADgY=.9d2d66e4-f49f-4e72-ba79-aafa713ebf2e@github.com>

On Thu, 15 Sep 2022 05:32:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>IIRC, in hotspot we need two reviews, one Reviewer, the other at least Contributor. Maybe one of your team should propose you as Contributor (@coleenp?), then your reviews count too. I think you have the required number of patches already.

I've heard Reviewer + Author is fine, but I'll get a Contributor to look at this. I think I have the required number of patches, but not all of them are non-trivial so I'm waiting a bit to remove any doubt about the outcome of a vote.

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

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

From shade at openjdk.org  Thu Sep 15 10:52:34 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 10:52:34 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump
Message-ID: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>

Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. We can homogenize the stack printing across all architectures. 

I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.

As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.

x86_64 hs_err before:

Top of Stack: (sp=0x00007fdab92650b0)
0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 


x86_64 hs_err after:

Top of Stack: (sp=0x00007f10ccb1d0b0)
0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
0x00007f10ccb1d200:   000000000000003b 0000004100000000
0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 


Testing:
  - [x] Eyeballing ad-hoc crash logs
  - [x] Build: linux-x86_64-server-fastdebug
  - [x] Build: linux-x86_64-zero-fastdebug
  - [x] Build: linux-x86-server-fastdebug
  - [x] Cross-build: linux-aarch64-server-fastdebug
  - [x] Cross-build: linux-arm-server-fastdebug
  - [x] Cross-build: linux-riscv64-server-fastdebug
  - [x] Cross-build: linux-s390x-server-fastdebug
  - [x] Cross-build: linux-ppc64le-server-fastdebug
  - [x] Cross-build: linux-ppc64-server-fastdebug

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

Commit messages:
 - Fix

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

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

From adinn at openjdk.org  Thu Sep 15 11:15:51 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 15 Sep 2022 11:15:51 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump
In-Reply-To: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
Message-ID: <dqNUOirIcnks7UqMSN1uIojGt4-ZWhaXRU2_AsBrtJc=.206b01f2-3e49-4192-8857-59d9d42fc447@github.com>

On Thu, 15 Sep 2022 10:44:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
> 
> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
> 
> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
> 
> x86_64 hs_err before:
> 
> Top of Stack: (sp=0x00007fdab92650b0)
> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
> 
> 
> x86_64 hs_err after:
> 
> Top of Stack: (sp=0x00007f10ccb1d0b0)
> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
> 
> 
> Testing:
>   - [x] Eyeballing ad-hoc crash logs
>   - [x] Build: linux-x86_64-server-fastdebug
>   - [x] Build: linux-x86_64-zero-fastdebug
>   - [x] Build: linux-x86-server-fastdebug
>   - [x] Cross-build: linux-aarch64-server-fastdebug
>   - [x] Cross-build: linux-arm-server-fastdebug
>   - [x] Cross-build: linux-riscv64-server-fastdebug
>   - [x] Cross-build: linux-s390x-server-fastdebug
>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>   - [x] Cross-build: linux-ppc64-server-fastdebug

Looks great!

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

Marked as reviewed by adinn (Reviewer).

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

From stuefe at openjdk.org  Thu Sep 15 11:44:46 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Sep 2022 11:44:46 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <09ODl20Suqt8tuQw2Am5ojoB5SO9qtTCIJqUwjeADgY=.9d2d66e4-f49f-4e72-ba79-aafa713ebf2e@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
 <Zlt9EPWTR6FZa2JJiOU4zCzz36Xg7w0FMoJ3jAzfv4g=.3fd58b26-631d-4eae-9580-8a39f8589591@github.com>
 <8RvTrL5rcgeAkqyo3f7vmCtzZKkdy2ykD1N6Nt3MTTg=.c55ee44a-3855-41ea-b09d-c7e779270881@github.com>
 <09ODl20Suqt8tuQw2Am5ojoB5SO9qtTCIJqUwjeADgY=.9d2d66e4-f49f-4e72-ba79-aafa713ebf2e@github.com>
Message-ID: <Fm6iuWVu2vK9cazGjF-xyHq2E3CxTZk46SYve5ajB4c=.793a15d6-cf8e-4175-9eab-5129bd5236e1@github.com>

On Thu, 15 Sep 2022 08:53:14 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> 
> > IIRC, in hotspot we need two reviews, one Reviewer, the other at least Contributor. Maybe one of your team should propose you as Contributor (@coleenp?), then your reviews count too. I think you have the required number of patches already.
> 
> I've heard Reviewer + Author is fine, but I'll get a Contributor to look at this. I think I have the required number of patches, but not all of them are non-trivial so I'm waiting a bit to remove any doubt about the outcome of a vote.

Maybe you are right and Author is sufficient for the second vote. Whenever I look for the relevant wiki page I cannot find it :)

Up to  @navyxliu of course, but since we are not stormed by willing reviewers, I'd just push.

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

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

From stefank at openjdk.org  Thu Sep 15 12:15:41 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Sep 2022 12:15:41 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump
In-Reply-To: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
Message-ID: <h4Mp3vDtOKZ9GR9IraoUtC4Go4PGdqinydQqI6r1WAw=.515846e0-ca05-443d-8951-9b3f7a35c0c3@github.com>

On Thu, 15 Sep 2022 10:44:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
> 
> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
> 
> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
> 
> x86_64 hs_err before:
> 
> Top of Stack: (sp=0x00007fdab92650b0)
> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
> 
> 
> x86_64 hs_err after:
> 
> Top of Stack: (sp=0x00007f10ccb1d0b0)
> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
> 
> 
> Testing:
>   - [x] Eyeballing ad-hoc crash logs
>   - [x] Build: linux-x86_64-server-fastdebug
>   - [x] Build: linux-x86_64-zero-fastdebug
>   - [x] Build: linux-x86-server-fastdebug
>   - [x] Cross-build: linux-aarch64-server-fastdebug
>   - [x] Cross-build: linux-arm-server-fastdebug
>   - [x] Cross-build: linux-riscv64-server-fastdebug
>   - [x] Cross-build: linux-s390x-server-fastdebug
>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>   - [x] Cross-build: linux-ppc64-server-fastdebug

+1

I would consider hiding `sizeof(intptr_t)` from the call sites. Seems like unnecessary noise to me.

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

Marked as reviewed by stefank (Reviewer).

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

From stuefe at openjdk.org  Thu Sep 15 13:21:49 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Sep 2022 13:21:49 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump
In-Reply-To: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
Message-ID: <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>

On Thu, 15 Sep 2022 10:44:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
> 
> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
> 
> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
> 
> x86_64 hs_err before:
> 
> Top of Stack: (sp=0x00007fdab92650b0)
> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
> 
> 
> x86_64 hs_err after:
> 
> Top of Stack: (sp=0x00007f10ccb1d0b0)
> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
> 
> 
> Testing:
>   - [x] Eyeballing ad-hoc crash logs
>   - [x] Build: linux-x86_64-server-fastdebug
>   - [x] Build: linux-x86_64-zero-fastdebug
>   - [x] Build: linux-x86-server-fastdebug
>   - [x] Cross-build: linux-aarch64-server-fastdebug
>   - [x] Cross-build: linux-arm-server-fastdebug
>   - [x] Cross-build: linux-riscv64-server-fastdebug
>   - [x] Cross-build: linux-s390x-server-fastdebug
>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>   - [x] Cross-build: linux-ppc64-server-fastdebug

I dislike a bit that the new function lives in os.hpp since it is a rather specific function used in one place only and would better live locally in vmError.cpp. 

I guess it needs to be this way if you want to keep the patch small, because we have no platform-independent API for extracting PC and SP from a context (which would be trivial to implement, but I don't know how far you want to go).

src/hotspot/share/runtime/os.hpp line 766:

> 764:   static void print_signal_handlers(outputStream* st, char* buf, size_t buflen);
> 765:   static void print_date_and_time(outputStream* st, char* buf, size_t buflen);
> 766:   static void print_stack(outputStream* st, address sp, int unitsize);

I'd rename this to something like `print_stack_as_hex_dump()` or similar since print_stack suggests you print a stack, and because we already have `platform_print_native_stack()` and `get_native_stack()`.

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

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

From shade at openjdk.org  Thu Sep 15 14:27:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 14:27:46 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump
In-Reply-To: <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
Message-ID: <trMcz3DfB9qCYe46dqGvbbmRB-4w5EnmDMmTK3YcVjw=.3b737b0e-8359-4a22-8226-521a67eda439@github.com>

On Thu, 15 Sep 2022 13:15:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
>> 
>> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
>> 
>> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
>> 
>> x86_64 hs_err before:
>> 
>> Top of Stack: (sp=0x00007fdab92650b0)
>> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
>> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
>> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
>> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
>> 
>> 
>> x86_64 hs_err after:
>> 
>> Top of Stack: (sp=0x00007f10ccb1d0b0)
>> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
>> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
>> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
>> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
>> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
>> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
>> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
>> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
>> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
>> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
>> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
>> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
>> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
>> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
>> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
>> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
>> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
>> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
>> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
>> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
>> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
>> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
>> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
>> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
>> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
>> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
>> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
>> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
>> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
>> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
>> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
>> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
>> 
>> 
>> Testing:
>>   - [x] Eyeballing ad-hoc crash logs
>>   - [x] Build: linux-x86_64-server-fastdebug
>>   - [x] Build: linux-x86_64-zero-fastdebug
>>   - [x] Build: linux-x86-server-fastdebug
>>   - [x] Cross-build: linux-aarch64-server-fastdebug
>>   - [x] Cross-build: linux-arm-server-fastdebug
>>   - [x] Cross-build: linux-riscv64-server-fastdebug
>>   - [x] Cross-build: linux-s390x-server-fastdebug
>>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>>   - [x] Cross-build: linux-ppc64-server-fastdebug
>
> src/hotspot/share/runtime/os.hpp line 766:
> 
>> 764:   static void print_signal_handlers(outputStream* st, char* buf, size_t buflen);
>> 765:   static void print_date_and_time(outputStream* st, char* buf, size_t buflen);
>> 766:   static void print_stack(outputStream* st, address sp, int unitsize);
> 
> I'd rename this to something like `print_stack_as_hex_dump()` or similar since print_stack suggests you print a stack, and because we already have `platform_print_native_stack()` and `get_native_stack()`.

Yeah. This looks like a helper function for `print_tos_pc`, so I can just name it `print_tos` -- it would be enough to disambiguate against the "real" stack printing functions. It also captures the intent better: we are not printing the entirety of the stack, or even care if we cross any stack frames, etc.

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

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

From jsjolen at openjdk.org  Thu Sep 15 14:27:51 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 15 Sep 2022 14:27:51 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
Message-ID: <tTDNqGKVOdPeJicU44mY66dvNEVTpN_IyFW-Ej8Bx4E=.0c270a80-a6d1-45d7-83be-9e083336463f@github.com>

On Tue, 13 Sep 2022 06:49:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
>> 
>> 1. Overhead of pointer-based linked-list. 
>> 2. strdup of message contents
>> 
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>> 
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
>> 
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Buffer::set_capacity and make its _capacity constant.

Just integrating sounds good to me.

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

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

From stuefe at openjdk.org  Thu Sep 15 14:37:44 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Sep 2022 14:37:44 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump
In-Reply-To: <trMcz3DfB9qCYe46dqGvbbmRB-4w5EnmDMmTK3YcVjw=.3b737b0e-8359-4a22-8226-521a67eda439@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
 <trMcz3DfB9qCYe46dqGvbbmRB-4w5EnmDMmTK3YcVjw=.3b737b0e-8359-4a22-8226-521a67eda439@github.com>
Message-ID: <950z4xek1XXy9JFfoX1FAk31r_LNkD4jIH0VJE5W8yg=.a4015897-2f49-400d-90ff-e6ac64806128@github.com>

On Thu, 15 Sep 2022 14:25:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 766:
>> 
>>> 764:   static void print_signal_handlers(outputStream* st, char* buf, size_t buflen);
>>> 765:   static void print_date_and_time(outputStream* st, char* buf, size_t buflen);
>>> 766:   static void print_stack(outputStream* st, address sp, int unitsize);
>> 
>> I'd rename this to something like `print_stack_as_hex_dump()` or similar since print_stack suggests you print a stack, and because we already have `platform_print_native_stack()` and `get_native_stack()`.
>
> Yeah. This looks like a helper function for `print_tos_pc`, so I can just name it `print_tos` -- it would be enough to disambiguate against the "real" stack printing functions. It also captures the intent better: we are not printing the entirety of the stack, or even care if we cross any stack frames, etc.

print_tos_pc itself is weird, since it does two unrelated things, but this is fine for a separate cleanup. Thanks for renaming.

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

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

From shade at openjdk.org  Thu Sep 15 15:00:49 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 15:00:49 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
Message-ID: <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>

> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
> 
> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
> 
> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
> 
> x86_64 hs_err before:
> 
> Top of Stack: (sp=0x00007fdab92650b0)
> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
> 
> 
> x86_64 hs_err after:
> 
> Top of Stack: (sp=0x00007f10ccb1d0b0)
> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
> 
> 
> Testing:
>   - [x] Eyeballing ad-hoc crash logs
>   - [x] Build: linux-x86_64-server-fastdebug
>   - [x] Build: linux-x86_64-zero-fastdebug
>   - [x] Build: linux-x86-server-fastdebug
>   - [x] Cross-build: linux-aarch64-server-fastdebug
>   - [x] Cross-build: linux-arm-server-fastdebug
>   - [x] Cross-build: linux-riscv64-server-fastdebug
>   - [x] Cross-build: linux-s390x-server-fastdebug
>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>   - [x] Cross-build: linux-ppc64-server-fastdebug

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

 - Rename to print_tos
 - Drop stack unitsize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10282/files
  - new: https://git.openjdk.org/jdk/pull/10282/files/98a27d9c..a9c35f88

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

  Stats: 17 lines in 13 files changed: 2 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/10282.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10282/head:pull/10282

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

From shade at openjdk.org  Thu Sep 15 15:00:52 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 15:00:52 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <h4Mp3vDtOKZ9GR9IraoUtC4Go4PGdqinydQqI6r1WAw=.515846e0-ca05-443d-8951-9b3f7a35c0c3@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <h4Mp3vDtOKZ9GR9IraoUtC4Go4PGdqinydQqI6r1WAw=.515846e0-ca05-443d-8951-9b3f7a35c0c3@github.com>
Message-ID: <T85PSiWmJrmCtqUYGVlxdjFlEABhA7WQj6yKgC4vZy8=.75b1b54a-f03a-4af0-aded-32109d058c4a@github.com>

On Thu, 15 Sep 2022 12:11:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I would consider hiding `sizeof(intptr_t)` from the call sites. Seems like unnecessary noise to me.

Right. Stack dump is one of those things where we expect word-granularity (almost?) everywhere. Done in new commit.

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

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

From shade at openjdk.org  Thu Sep 15 15:00:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 15:00:51 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
Message-ID: <TjCfH-KzEvf91oKfMjVzKfFcu_4BcupKLpxe2wZeAPk=.2142094e-8514-4644-a73d-e13bfd6f1de6@github.com>

On Thu, 15 Sep 2022 13:18:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I guess it needs to be this way if you want to keep the patch small, because we have no platform-independent API for extracting PC and SP from a context (which would be trivial to implement, but I don't know how far you want to go).

One of the reasons why `print_instruction` is separate and called via os_cpu-specific code is that arches select the unit size knowing the instruction size. Granted, we can do the helpers that expose both SP, PC, and insn unit size.

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

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

From shade at openjdk.org  Thu Sep 15 15:00:54 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 15:00:54 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <950z4xek1XXy9JFfoX1FAk31r_LNkD4jIH0VJE5W8yg=.a4015897-2f49-400d-90ff-e6ac64806128@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
 <trMcz3DfB9qCYe46dqGvbbmRB-4w5EnmDMmTK3YcVjw=.3b737b0e-8359-4a22-8226-521a67eda439@github.com>
 <950z4xek1XXy9JFfoX1FAk31r_LNkD4jIH0VJE5W8yg=.a4015897-2f49-400d-90ff-e6ac64806128@github.com>
Message-ID: <BeHQVHIrMkOGqNv2_VRViQIdYZQI4mhUQcQqNWkMgsc=.f9ec3af0-5f7e-4766-8850-749a1840d018@github.com>

On Thu, 15 Sep 2022 14:34:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yeah. This looks like a helper function for `print_tos_pc`, so I can just name it `print_tos` -- it would be enough to disambiguate against the "real" stack printing functions. It also captures the intent better: we are not printing the entirety of the stack, or even care if we cross any stack frames, etc.
>
> print_tos_pc itself is weird, since it does two unrelated things, but this is fine for a separate cleanup. Thanks for renaming.

Done in new commit.

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

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

From shade at openjdk.org  Thu Sep 15 17:13:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Sep 2022 17:13:08 GMT
Subject: RFR: 8293872: Make runtime/Thread/ThreadCountLimit.java more robust
Message-ID: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>

I am seeing this failure frequently on linux-x86:


$ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
...
stdout:
[1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
[1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
# An error report file with more information is saved as:
# /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
[2.019s][warning][os ] Loading hsdis library failed


It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.

I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.

Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.

After [JDK-8255450](https://bugs.openjdk.org/browse/JDK-8255450), this test still runs in tier2.

Additional testing:
 - [x] Linux x86_32 fastdebug, affected test in 100 repetitions (all passed!)
 - [ ]  Linux x86_64 fastdebug, affected test in 100 repetitions

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

Commit messages:
 - Fix

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

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

From ccheung at openjdk.org  Thu Sep 15 18:08:25 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 Sep 2022 18:08:25 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock
Message-ID: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>

Please review this fix which involves:

- acquire the `Module_lock` before calling `modules_do`;
- move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
- save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.

Passed tiers 1 - 3 testing.

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

Commit messages:
 - 8292202: modules_do is called without Module_lock

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

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

From xliu at openjdk.org  Thu Sep 15 18:36:51 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 15 Sep 2022 18:36:51 GMT
Subject: RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v9]
In-Reply-To: <Fm6iuWVu2vK9cazGjF-xyHq2E3CxTZk46SYve5ajB4c=.793a15d6-cf8e-4175-9eab-5129bd5236e1@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
 <xD9-ZMoaLzG58j2UfccdtaNE7kYfmwrKDBYG5S8n2us=.c0e3c5e7-a6f7-4f52-bb7d-e98dfa157774@github.com>
 <Zlt9EPWTR6FZa2JJiOU4zCzz36Xg7w0FMoJ3jAzfv4g=.3fd58b26-631d-4eae-9580-8a39f8589591@github.com>
 <8RvTrL5rcgeAkqyo3f7vmCtzZKkdy2ykD1N6Nt3MTTg=.c55ee44a-3855-41ea-b09d-c7e779270881@github.com>
 <09ODl20Suqt8tuQw2Am5ojoB5SO9qtTCIJqUwjeADgY=.9d2d66e4-f49f-4e72-ba79-aafa713ebf2e@github.com>
 <Fm6iuWVu2vK9cazGjF-xyHq2E3CxTZk46SYve5ajB4c=.793a15d6-cf8e-4175-9eab-5129bd5236e1@github.com>
Message-ID: <ipJIn6YlBg6_sm9P5Lsz-oJLhF-_lWrIHeW5sq4tL7g=.6b75e7e4-d1f3-4d6e-8407-4ed5499fed6e@github.com>

On Thu, 15 Sep 2022 11:40:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>>IIRC, in hotspot we need two reviews, one Reviewer, the other at least Contributor. Maybe one of your team should propose you as Contributor (@coleenp?), then your reviews count too. I think you have the required number of patches already.
>> 
>> I've heard Reviewer + Author is fine, but I'll get a Contributor to look at this. I think I have the required number of patches, but not all of them are non-trivial so I'm waiting a bit to remove any doubt about the outcome of a vote.
>
>> 
>> > IIRC, in hotspot we need two reviews, one Reviewer, the other at least Contributor. Maybe one of your team should propose you as Contributor (@coleenp?), then your reviews count too. I think you have the required number of patches already.
>> 
>> I've heard Reviewer + Author is fine, but I'll get a Contributor to look at this. I think I have the required number of patches, but not all of them are non-trivial so I'm waiting a bit to remove any doubt about the outcome of a vote.
> 
> Maybe you are right and Author is sufficient for the second vote. Whenever I look for the relevant wiki page I cannot find it :)
> 
> Up to  @navyxliu of course, but since we are not stormed by willing reviewers, I'd just push.

Thanks @tstuefe and @jdksjolen for reviewing this!
--lx

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

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

From xliu at openjdk.org  Thu Sep 15 18:36:52 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 15 Sep 2022 18:36:52 GMT
Subject: Integrated: 8292989: Avoid dynamic memory in AsyncLogWriter
In-Reply-To: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
References: <GVAjltIvllL3CAxKRmzPyYFF3tT0oymcypAIz4hdFHI=.a18b59d7-b434-486e-8d54-ef8b88379dd9@github.com>
Message-ID: <Xw3XxvVSV3dHaN5G_yjZNgzQNPTRuDMscAsWyOldMms=.c17beade-a378-43e0-aa4b-ef1d1622848f@github.com>

On Wed, 31 Aug 2022 01:10:09 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources. 
> 
> 1. Overhead of pointer-based linked-list. 
> 2. strdup of message contents
> 
> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
> 
> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before. 
> 
> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.

This pull request has now been integrated.

Changeset: bf79f99c
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf79f99c0c61fc36b80cd8550e5c70e158338ef4
Stats:     504 lines in 5 files changed: 267 ins; 199 del; 38 mod

8292989: Avoid dynamic memory in AsyncLogWriter

Reviewed-by: jsjolen, stuefe

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

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

From iklam at openjdk.org  Thu Sep 15 18:39:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 Sep 2022 18:39:59 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock
In-Reply-To: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
Message-ID: <VDQ52ZWKUtzcQ7t9ZethsBTNG7c6QUUwRFIqSrvHAxM=.ca750f18-a4c7-4570-9a6d-5bf85bca0461@github.com>

On Thu, 15 Sep 2022 18:01:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this fix which involves:
> 
> - acquire the `Module_lock` before calling `modules_do`;
> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
> 
> Passed tiers 1 - 3 testing.

Looks good. A minor suggestion to simplify the code.

src/hotspot/share/classfile/classLoaderExt.cpp line 99:

> 97:         char* path_copy = NEW_RESOURCE_ARRAY(char, strlen(path) + 1);
> 98:         strcpy(path_copy, path);
> 99:         _module_paths->at_put_grow(_total_count++, path_copy);

You can use `_module_paths->append()` to avoid keeping the `_total_count`

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

Marked as reviewed by iklam (Reviewer).

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

From dcubed at openjdk.org  Thu Sep 15 19:38:02 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 15 Sep 2022 19:38:02 GMT
Subject: RFR: 8293875: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
Message-ID: <zA8Rm8Cxk_tEV8ZbeustKSLUofAAhjvsOH0eKS27BaE=.55b202c2-9ca9-44a7-95a5-66fc2b344ed0@github.com>

A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.

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

Commit messages:
 - 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64

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

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

From bpb at openjdk.org  Thu Sep 15 19:38:02 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Sep 2022 19:38:02 GMT
Subject: RFR: 8293875: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <zA8Rm8Cxk_tEV8ZbeustKSLUofAAhjvsOH0eKS27BaE=.55b202c2-9ca9-44a7-95a5-66fc2b344ed0@github.com>
References: <zA8Rm8Cxk_tEV8ZbeustKSLUofAAhjvsOH0eKS27BaE=.55b202c2-9ca9-44a7-95a5-66fc2b344ed0@github.com>
Message-ID: <iHbsYdueBmRnND1B02A6dXD_XmUSKWKT6y1AXWhUtDM=.fe4d7661-1161-46d5-b616-0c4b65f43edc@github.com>

On Thu, 15 Sep 2022 19:27:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.

Marked as reviewed by bpb (Reviewer).

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

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

From dcubed at openjdk.org  Thu Sep 15 19:42:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 15 Sep 2022 19:42:10 GMT
Subject: RFR: 8293875: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <iHbsYdueBmRnND1B02A6dXD_XmUSKWKT6y1AXWhUtDM=.fe4d7661-1161-46d5-b616-0c4b65f43edc@github.com>
References: <zA8Rm8Cxk_tEV8ZbeustKSLUofAAhjvsOH0eKS27BaE=.55b202c2-9ca9-44a7-95a5-66fc2b344ed0@github.com>
 <iHbsYdueBmRnND1B02A6dXD_XmUSKWKT6y1AXWhUtDM=.fe4d7661-1161-46d5-b616-0c4b65f43edc@github.com>
Message-ID: <1rdlpqwgRq-3sfdp-YeodVc5B2fZZy_VQz9iu8FImrs=.88cebebd-177b-4077-a290-e585070116f4@github.com>

On Thu, 15 Sep 2022 19:32:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the fast review.

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

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

From dcubed at openjdk.org  Thu Sep 15 19:42:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 15 Sep 2022 19:42:10 GMT
Subject: Integrated: 8293875: ProblemList
 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64
In-Reply-To: <zA8Rm8Cxk_tEV8ZbeustKSLUofAAhjvsOH0eKS27BaE=.55b202c2-9ca9-44a7-95a5-66fc2b344ed0@github.com>
References: <zA8Rm8Cxk_tEV8ZbeustKSLUofAAhjvsOH0eKS27BaE=.55b202c2-9ca9-44a7-95a5-66fc2b344ed0@github.com>
Message-ID: <Q12Bx7WhHzqv3Mlenbwxd7fuxNITDaGpiuAtAJuIOzs=.88dccb82-d8db-43fd-a0ff-031ee5b25272@github.com>

On Thu, 15 Sep 2022 19:27:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64.

This pull request has now been integrated.

Changeset: 6beeb847
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6beeb8471ccf140e59864d7f983e1d9ad741309c
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64

Reviewed-by: bpb

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

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

From iklam at openjdk.org  Thu Sep 15 21:18:16 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 Sep 2022 21:18:16 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive heap
Message-ID: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>

Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.

At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.

This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.


Notes for reviewers:

- At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
- At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
- The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
- Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

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

Commit messages:
 - clean up
 - 8293291: Simplify relocation of native pointers in archive heap

Changes: https://git.openjdk.org/jdk/pull/10296/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293291
  Stats: 418 lines in 16 files changed: 185 ins; 153 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/10296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10296/head:pull/10296

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

From ccheung at openjdk.org  Thu Sep 15 21:43:51 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 Sep 2022 21:43:51 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v2]
In-Reply-To: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
Message-ID: <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>

> Please review this fix which involves:
> 
> - acquire the `Module_lock` before calling `modules_do`;
> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
> 
> Passed tiers 1 - 3 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  get rid of the _total_count field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10291/files
  - new: https://git.openjdk.org/jdk/pull/10291/files/46fc54a0..9f4e67f9

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

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

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

From ccheung at openjdk.org  Thu Sep 15 21:43:53 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 Sep 2022 21:43:53 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v2]
In-Reply-To: <VDQ52ZWKUtzcQ7t9ZethsBTNG7c6QUUwRFIqSrvHAxM=.ca750f18-a4c7-4570-9a6d-5bf85bca0461@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
 <VDQ52ZWKUtzcQ7t9ZethsBTNG7c6QUUwRFIqSrvHAxM=.ca750f18-a4c7-4570-9a6d-5bf85bca0461@github.com>
Message-ID: <RLK6_o2X1ZXABUREXofyprFVVm8KqFsk_ybv3d_Qnlo=.1e4aa42c-3210-46e7-968f-b66e0f38b0d2@github.com>

On Thu, 15 Sep 2022 18:33:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get rid of the _total_count field
>
> src/hotspot/share/classfile/classLoaderExt.cpp line 99:
> 
>> 97:         char* path_copy = NEW_RESOURCE_ARRAY(char, strlen(path) + 1);
>> 98:         strcpy(path_copy, path);
>> 99:         _module_paths->at_put_grow(_total_count++, path_copy);
> 
> You can use `_module_paths->append()` to avoid keeping the `_total_count`

Fixed.
Thanks for your review.

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

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

From lzhai at openjdk.org  Fri Sep 16 07:44:20 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Fri, 16 Sep 2022 07:44:20 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
Message-ID: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>

Hi,

@dumasun reported the issue:

Configured with jfx-ls-modular-sdk:


configure --with-import-modules=modular-sdk


`make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:


----------System.err:(11/697)----------
java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
    at FXLauncherTest.main(FXLauncherTest.java:451)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
    at java.base/java.lang.Thread.run(Thread.java:1589)

JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK


Thanks,
Leslie Zhai

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

Commit messages:
 - 8293910: tools/launcher/FXLauncherTest.java fail with jfx

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

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

From lzhai at openjdk.org  Fri Sep 16 07:44:20 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Fri, 16 Sep 2022 07:44:20 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <4yQuAMPyhIP6siABor_pq18XKTvvhZ2vX5_ptWy22ww=.3f45ec67-229b-4d40-a205-f069c6f43c31@github.com>

On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

Hi,

Thank @kevinrushforth [8202553: Update FXLauncherTest as part of removing JavaFX from JDK](https://github.com/openjdk/jdk/commit/8af434d695ca2f8da8fcdbbf058b85d4e79fbd1a).  And jdk11u-dev Passed:


make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/tools/launcher/FXLauncherTest.java     1     1     0     0   
==============================
TEST SUCCESS


So I just skip the test for configured with jfx-ls-modular-sdk.

Please review my patch.

Thanks,
Leslie Zhai

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

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

From duke at openjdk.org  Fri Sep 16 08:34:50 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 16 Sep 2022 08:34:50 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
Message-ID: <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>

On Sat, 27 Aug 2022 00:20:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows
>
> test/jdk/tools/launcher/I18NArgTest.java line 147:
> 
>> 145:             for (int i = 0; i < sysPropVal.length(); i++) {
>> 146:                 sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
>> 147:             }
> 
> It's OK as it stands, but this loop could be replaced with a `HexFormat` one-liner.

I'm sorry, I can't replace this code with a HexFormat one-line. Do you have an example code?

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

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

From duke at openjdk.org  Fri Sep 16 08:50:14 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 16 Sep 2022 08:50:14 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v4]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <Sjiz9sPPIDsN6a1QpZ-R8k_eOLt6aQJdQrQrzIwYL1I=.f34f9d47-c300-4445-a996-03ef6270bdc4@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/4dbf952d..e22d35c5

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

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

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

From duke at openjdk.org  Fri Sep 16 08:50:15 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 16 Sep 2022 08:50:15 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
Message-ID: <HrxcMxvmYOWbX_XpNetC-b19478G1wDJ7XjNfXsR4dQ=.854dc32e-e8b5-45a0-b77b-a121500706ac@github.com>

On Sat, 27 Aug 2022 00:19:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows
>
> test/jdk/tools/launcher/I18NArgTest.java line 104:
> 
>> 102:         // we expect that system property value to be passed along to the main method with the
>> 103:         // correct encoding
>> 104:         // If <unicodestr> contains space or tab, it should beenclosed with double quotes.
> 
> Nit: space is missing between "be" and "enclosed"

Thank you for your comment, I fixed it.

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

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

From stefank at openjdk.org  Fri Sep 16 09:22:42 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Sep 2022 09:22:42 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>
Message-ID: <4koVnZ1gzNgcv4jDyHfuR1mFvKgw-Bt7lCzYMyq0fMc=.7257cfc9-f339-4563-b200-08d8cec28755@github.com>

On Thu, 15 Sep 2022 15:00:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
>> 
>> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
>> 
>> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
>> 
>> x86_64 hs_err before:
>> 
>> Top of Stack: (sp=0x00007fdab92650b0)
>> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
>> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
>> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
>> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
>> 
>> 
>> x86_64 hs_err after:
>> 
>> Top of Stack: (sp=0x00007f10ccb1d0b0)
>> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
>> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
>> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
>> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
>> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
>> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
>> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
>> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
>> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
>> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
>> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
>> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
>> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
>> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
>> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
>> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
>> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
>> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
>> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
>> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
>> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
>> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
>> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
>> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
>> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
>> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
>> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
>> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
>> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
>> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
>> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
>> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
>> 
>> 
>> Testing:
>>   - [x] Eyeballing ad-hoc crash logs
>>   - [x] Build: linux-x86_64-server-fastdebug
>>   - [x] Build: linux-x86_64-zero-fastdebug
>>   - [x] Build: linux-x86-server-fastdebug
>>   - [x] Cross-build: linux-aarch64-server-fastdebug
>>   - [x] Cross-build: linux-arm-server-fastdebug
>>   - [x] Cross-build: linux-riscv64-server-fastdebug
>>   - [x] Cross-build: linux-s390x-server-fastdebug
>>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>>   - [x] Cross-build: linux-ppc64-server-fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename to print_tos
>  - Drop stack unitsize

Marked as reviewed by stefank (Reviewer).

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

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

From rehn at openjdk.org  Fri Sep 16 10:08:30 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 16 Sep 2022 10:08:30 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to native
 transitions
Message-ID: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>

As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.

Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).

Running t1-5 with UseSystemMemoryBarrier on.

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

Commit messages:
 - Avoid fence

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

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

From shade at openjdk.org  Fri Sep 16 10:49:45 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 16 Sep 2022 10:49:45 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <yK2T5s-Tm8op4DC0hlCMm2eZhn4a0Yf35cEHV7lxcaA=.4f60790d-8a48-449e-a1fa-5bf146ce35be@github.com>
Message-ID: <6msjjpVcKBuH7ZNfTGn1If7udw0x5Btt66LL-L4z0UI=.4915f4a9-de6d-4986-99a0-693382b67569@github.com>

On Thu, 15 Sep 2022 13:18:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Rename to print_tos
>>  - Drop stack unitsize
>
> I dislike a bit that the new function lives in os.hpp since it is a rather specific function used in one place only and would better live locally in vmError.cpp. 
> 
> I guess it needs to be this way if you want to keep the patch small, because we have no platform-independent API for extracting PC and SP from a context (which would be trivial to implement, but I don't know how far you want to go).

@tstuefe  -- happy with current PR, or?

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

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

From mdoerr at openjdk.org  Fri Sep 16 11:08:51 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 16 Sep 2022 11:08:51 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions
In-Reply-To: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
Message-ID: <oLYw0F_0cRsOjxda9yAl-QcMJbEk6xlzhE5lSm4Duxg=.cce10b9a-3244-44bd-945f-e14341411d76@github.com>

On Fri, 16 Sep 2022 10:01:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
> 
> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
> 
> Running t1-5 with UseSystemMemoryBarrier on.

Very cool! Both, `_thread_state` and `_polling_word` are volatile, so the C++ compiler is not allowed to mess up the accesses. The speedup should more than justify the overhead of the `SYS_membarrier` call. I hope that we can use it in production at some point of time.

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

Marked as reviewed by mdoerr (Reviewer).

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

From rehn at openjdk.org  Fri Sep 16 12:24:45 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 16 Sep 2022 12:24:45 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
Message-ID: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>

> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
> 
> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
> 
> Running t1-5 with UseSystemMemoryBarrier on.

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

  Use proper accessors for _thread_state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10302/files
  - new: https://git.openjdk.org/jdk/pull/10302/files/d1f143ed..52bad66c

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

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

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

From rehn at openjdk.org  Fri Sep 16 12:24:46 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 16 Sep 2022 12:24:46 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions
In-Reply-To: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
Message-ID: <wLUulBczMv21nY6FAp2xdW2dGcMYeKFRCLjfDoDxl4s=.a987ae72-599f-4a39-a94a-e6abae9a83e8@github.com>

On Fri, 16 Sep 2022 10:01:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
> 
> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
> 
> Running t1-5 with UseSystemMemoryBarrier on.

Thanks, great.

But since you bring it up. We should use correct accessors for _thread_state.
Fixed that, please have a second look @TheRealMDoerr.

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

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

From jsjolen at openjdk.org  Fri Sep 16 12:30:20 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 16 Sep 2022 12:30:20 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
Message-ID: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>

Hi,

May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.

Tier 2 and 3 tests are currently running, all green so far.

Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873

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

Commit messages:
 - Simplify UL initialization

Changes: https://git.openjdk.org/jdk/pull/10307/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293873
  Stats: 99 lines in 10 files changed: 12 ins; 40 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/10307.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10307/head:pull/10307

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

From mdoerr at openjdk.org  Fri Sep 16 12:39:46 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 16 Sep 2022 12:39:46 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
Message-ID: <eXb7erGLsXe5wp5u8_HFFue3UQTrhY90rN7D6-7AKd4=.70cadf3a-447e-4ae4-be28-1fc97d253533@github.com>

On Fri, 16 Sep 2022 12:24:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
>> 
>> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
>> 
>> Running t1-5 with UseSystemMemoryBarrier on.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper accessors for _thread_state

Thanks for cleaning it up!

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

Marked as reviewed by mdoerr (Reviewer).

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

From alanb at openjdk.org  Fri Sep 16 12:40:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 12:40:44 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <4SHQpONNSUnaZdiFKPh9iPUS664dd88H2WYioUJOM8E=.e85b1f91-c404-40a2-80af-36f997ef2738@github.com>

On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

Can you try the following:

1. Change doFxCompile and doFxExec to use --upgrade-module-path instead of --module-path?
2. Remove the check for javafx.application.Application from the main method.

It would be interesting to check if it passes with regular builds of the JDK and your build that includes the JavaFX modules.

Note that the test summary includes the sentence "It also verifies that FX is, in fact, not included with the JDK" so that will need to change if the test is changed.

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

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

From rehn at openjdk.org  Fri Sep 16 12:54:42 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 16 Sep 2022 12:54:42 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <eXb7erGLsXe5wp5u8_HFFue3UQTrhY90rN7D6-7AKd4=.70cadf3a-447e-4ae4-be28-1fc97d253533@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
 <eXb7erGLsXe5wp5u8_HFFue3UQTrhY90rN7D6-7AKd4=.70cadf3a-447e-4ae4-be28-1fc97d253533@github.com>
Message-ID: <cyHMMUN46yo8Epb1b8nvugZe0Q1snZrYgOCt7tZVQCI=.4e1f299b-13f2-4915-b90b-be81303e1050@github.com>

On Fri, 16 Sep 2022 12:36:06 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for cleaning it up!

Thank you!

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

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

From kcr at openjdk.org  Fri Sep 16 13:05:39 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 13:05:39 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <rtNdDgOs61FHLvc3ZkpTZtxFw7B-WF-EDdwyOt_iXQk=.719a528e-44b7-4b07-8f07-df81c170beb2@github.com>

On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

It does seem worth trying `--patch-module` if the javafx.graphics module is present in the Java runtime. If that works, it is better than skipping the test, since you will then be able to continue testing the FX launcher.

Another possibility would be to go with your proposed solution of skipping the test if the javafx.graphics module is present, and provide a second test that is only run when the `javafx.graphics` module is present. In that case, you could test the actual FX launcher rather than the dummy implementation. This could either be done in this PR or as a follow-on test bug.

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

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

From adinn at openjdk.org  Fri Sep 16 13:10:59 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 16 Sep 2022 13:10:59 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>
Message-ID: <2WXhF21rT9BtMeb0I6SSLCKytYLr1jmH5TfoZZ8oNjI=.ace91b92-e759-4809-94af-d59dae329360@github.com>

On Thu, 15 Sep 2022 15:00:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
>> 
>> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
>> 
>> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
>> 
>> x86_64 hs_err before:
>> 
>> Top of Stack: (sp=0x00007fdab92650b0)
>> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
>> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
>> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
>> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
>> 
>> 
>> x86_64 hs_err after:
>> 
>> Top of Stack: (sp=0x00007f10ccb1d0b0)
>> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
>> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
>> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
>> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
>> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
>> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
>> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
>> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
>> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
>> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
>> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
>> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
>> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
>> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
>> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
>> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
>> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
>> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
>> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
>> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
>> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
>> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
>> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
>> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
>> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
>> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
>> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
>> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
>> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
>> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
>> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
>> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
>> 
>> 
>> Testing:
>>   - [x] Eyeballing ad-hoc crash logs
>>   - [x] Build: linux-x86_64-server-fastdebug
>>   - [x] Build: linux-x86_64-zero-fastdebug
>>   - [x] Build: linux-x86-server-fastdebug
>>   - [x] Cross-build: linux-aarch64-server-fastdebug
>>   - [x] Cross-build: linux-arm-server-fastdebug
>>   - [x] Cross-build: linux-riscv64-server-fastdebug
>>   - [x] Cross-build: linux-s390x-server-fastdebug
>>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>>   - [x] Cross-build: linux-ppc64-server-fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename to print_tos
>  - Drop stack unitsize

Still ok

Marked as reviewed by adinn (Reviewer).

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

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

From rriggs at openjdk.org  Fri Sep 16 14:01:44 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Sep 2022 14:01:44 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
 <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
Message-ID: <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>

On Fri, 16 Sep 2022 08:31:19 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> test/jdk/tools/launcher/I18NArgTest.java line 147:
>> 
>>> 145:             for (int i = 0; i < sysPropVal.length(); i++) {
>>> 146:                 sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
>>> 147:             }
>> 
>> It's OK as it stands, but this loop could be replaced with a `HexFormat` one-liner.
>
> I'm sorry, I can't replace this code with a HexFormat one-line. Do you have an example code?

Extract to a byte array with the appropriate charset and then HexFormat the bytearray.


    var SysPropHexVal = HexFormat.of().formatHex(sysPropVal.getBytes(StandardCharsets.UTF_16));

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

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

From pchilanomate at openjdk.org  Fri Sep 16 14:42:47 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 16 Sep 2022 14:42:47 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
Message-ID: <FmJAS88jge_JBJWw5qhbr0vh01g2esojLB8XQFKz4RY=.28132b94-4687-45e9-8309-5e4a032ed60f@github.com>

On Fri, 16 Sep 2022 12:24:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
>> 
>> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
>> 
>> Running t1-5 with UseSystemMemoryBarrier on.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper accessors for _thread_state

Looks good. Can't we do the same in ~ThreadBlockInVMPreprocess() for the blocked transition?

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

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

From stuefe at openjdk.org  Fri Sep 16 15:06:11 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Sep 2022 15:06:11 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy
Message-ID: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>

Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.

The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.

Also, the tests were expanded to test the display of empty loaders and empty parent loaders.

Thanks to @dholmes-ora for finding this bug.

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

Commit messages:
 - JDK-8293156-Dcmd-VM.classloaders-fails-to-print-the-full-hierarchy

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

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

From naoto at openjdk.org  Fri Sep 16 16:21:46 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Sep 2022 16:21:46 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
 <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
 <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>
Message-ID: <djedmAC0dHkHyeGxras2oHpdXMeY7EyXTYDyOnlPLTM=.eee0e269-cc45-4e90-8b15-ff7deae342bd@github.com>

On Fri, 16 Sep 2022 13:59:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'm sorry, I can't replace this code with a HexFormat one-line. Do you have an example code?
>
> Extract to a byte array with the appropriate charset and then HexFormat the bytearray.
> 
> 
>     var SysPropHexVal = HexFormat.of().formatHex(sysPropVal.getBytes(StandardCharsets.UTF_16));

Thanks, Roger. You beat me to it ?

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

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

From stuefe at openjdk.org  Fri Sep 16 16:23:49 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Sep 2022 16:23:49 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
In-Reply-To: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
Message-ID: <64dBk9q9MnvwD6Zh4FTp8ASWNhBCKUwEO8bfA2vwYf8=.888197a2-3d6e-4407-81e7-267546c747dc@github.com>

On Fri, 16 Sep 2022 12:22:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> but it might change how UL works before VM start up

This is a bit vague :)

How exactly does UL initialization change? Does it move? If yes, what happens if we log now before initialization?

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

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

From dlong at openjdk.org  Fri Sep 16 21:16:50 2022
From: dlong at openjdk.org (Dean Long)
Date: Fri, 16 Sep 2022 21:16:50 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v3]
In-Reply-To: <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>
Message-ID: <5jvtd7c7Dqz8w6oXi27Ez7BaS_zgIF_HCacIwDLsHHU=.85fbc7bf-b5bf-4776-9400-f8c53506e0e9@github.com>

On Thu, 15 Sep 2022 07:43:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> This fix simply removes the special case for interpreted frames in the shared method `Continuation::continuation_bottom_sender()`. I cannot see a reason for the distinction between interpreted and compiled frames. The shared code reference to `frame::interpreter_frame_last_sp()` is thereby eliminated.
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Only pass the actual sp when calling is_sp_in_continuation()
>  - Merge branch 'master'
>  - Merge branch 'master'
>  - Remove platform dependent method interpreter_frame_last_sp() from shared code

Actually, for interpreted --> interpreted, aarch64 and ppc64 seem to do the same trimming.  The difference is ppc64 does it in the caller, while aarch64 does it in the callee:

https://github.com/openjdk/jdk/blob/725f41ffd4b137aef3f83700b4e181e9d93368d4/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1578

So this would mean for interpreted --> compiled, ppc64 does trimming and aarch64 does not.

I also noticed that on ppc64, the value of unextended_sp for interpreted frames in inconsistent.  Whether or not it is the "max stack" value depends on who calls the frame constructor.  Some Loom code and sender_for_compiled_frame() sets unextended_sp the same as sp, while only sender_for_interpreter_frame() uses the "max stack" value.  Giving unextended_sp a consistent "canonical" value that is always inside the frame, no matter if the callee is interpreted or compiled, seems like it would make unextended_sp() valid for is_sp_in_continuation() as well.

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

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

From ccheung at openjdk.org  Fri Sep 16 22:47:06 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 16 Sep 2022 22:47:06 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <FQBzpmn_w9l468wUb5qJHrHI4YiVfQECiww2PpxPZAY=.73954241-f3cf-4277-a631-32c859b17152@github.com>

On Thu, 15 Sep 2022 20:49:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

I've a few minor comments. Thanks.

src/hotspot/share/cds/filemap.cpp line 1693:

> 1691:       int oopmap_idx = i * 2;
> 1692:       int ptrmap_idx = i * 2 + 1;
> 1693:       space_at(region_idx)->init_bitmaps(bitmaps->at(i*2), bitmaps->at(i*2 + 1));

Please add some comment on oopmap_idx and ptrmap_idx.

Line 1693 could be:
`space_at(region_idx)->init_bitmaps(bitmaps->at(oopmap_idx), bitmaps->at(ptrmap_idx));`

src/hotspot/share/cds/heapShared.cpp line 1848:

> 1846:   }
> 1847: 
> 1848:   log_info(cds, heap)("calculate_ptrmap: marked %d non-null native pointers our of "

typo: our -> out

src/hotspot/share/cds/metaspaceShared.cpp line 907:

> 905:                                                    GrowableArray<ArchiveHeapOopmapInfo>* oopmaps) {
> 906:   for (int i=0; i<regions->length(); i++) {
> 907:     ResourceBitMap oopmap = HeapShared::calculate_oopmap(regions->at(i));

Pre-existing: line 908.
While you're touching this code, please add a space before and after the '=' and '<'.

src/hotspot/share/include/cds.h line 59:

> 57:                               // for alignment purposed.
> 58:   size_t  _oopmap_offset;     // Bitmap for relocating oop fields in archived heap objects.
> 59:                               // (The base address is the botom of the BM region)

typo: botom -> bottom

src/hotspot/share/include/cds.h line 62:

> 60:   size_t  _oopmap_size_in_bits;
> 61:   size_t  _ptrmap_offset;     // Bitmap for relocating native pointer fields in archived heap objects.
> 62:                               // (The base address is the botom of the BM region).

typo: botom -> bottom

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

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

From lzhai at openjdk.org  Sat Sep 17 04:03:35 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Sat, 17 Sep 2022 04:03:35 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:

  8293910: Try --upgrade-module-path and --patch-module but still failed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10299/files
  - new: https://git.openjdk.org/jdk/pull/10299/files/04aa629e..360148f2

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

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

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

From lzhai at openjdk.org  Sat Sep 17 04:04:54 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Sat, 17 Sep 2022 04:04:54 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <QWlIpH0wHfeL22lFhFDCPTvQJGhNQkYVib6CBfNUK5M=.2ae16331-aeb5-4175-b8c6-2ed9923e7e3f@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

test/jdk/tools/launcher/FXLauncherTest.java line 249:

> 247:             fxCmds.add(2, "--add-modules=javafx.graphics");
> 248:         } else {
> 249:             fxCmds.add(1, "--upgrade-module-path=" + IMPORT_MODULE_DIR);

Hi @kevinrushforth @AlanBateman 

Please point out my fault if I misunderstanding.

Thanks,
Leslie Zhai

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

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

From stuefe at openjdk.org  Sat Sep 17 06:02:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 17 Sep 2022 06:02:09 GMT
Subject: RFR: JDK-8292073: NMT: remove unused constructor parameter from
 MallocHeader
Message-ID: <PmbX_-yXnBAI8RcIXMZ4WLh3cUwRAefqSM-Ed-bjS28=.805f2767-cb5c-4ac7-b669-7c7ca9a03891@github.com>

Trivial cleanup, removes an unused parameter from `MallocHeader` ctor

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

Commit messages:
 - JDK-8292073-NMT-remove-unused-constructor-parameter-from-MallocHeader

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

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

From lzhai at openjdk.org  Sat Sep 17 08:24:39 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Sat, 17 Sep 2022 08:24:39 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <rtNdDgOs61FHLvc3ZkpTZtxFw7B-WF-EDdwyOt_iXQk=.719a528e-44b7-4b07-8f07-df81c170beb2@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <rtNdDgOs61FHLvc3ZkpTZtxFw7B-WF-EDdwyOt_iXQk=.719a528e-44b7-4b07-8f07-df81c170beb2@github.com>
Message-ID: <RZcpjMcdxZIVWQG-kDVROCRIetR-n3ZqLnSMcEjf4us=.ca00eb6a-744d-4dd9-a0aa-23afdbd21f2d@github.com>

On Fri, 16 Sep 2022 13:02:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> It does seem worth trying `--patch-module` if the javafx.graphics module is present in the Java runtime. If that works, it is better than skipping the test, since you will then be able to continue testing the FX launcher.
> 
> Another possibility would be to go with your proposed solution of skipping the test if the javafx.graphics module is present, and provide a second test that is only run when the `javafx.graphics` module is present. In that case, you could test the actual FX launcher rather than the dummy implementation. This could either be done in this PR or as a follow-on test bug.

Hi @kevinrushforth @AlanBateman

I have tried `--upgrade-module-path` and `--patch-module` but still failed. Please point out my fault if I misunderstanding.

Thanks,
Leslie Zhai

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

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

From dcubed at openjdk.org  Sat Sep 17 15:33:56 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Sep 2022 15:33:56 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
Message-ID: <Aa7R_TBs210jY3-OBkLKFA2Ex78jhLoFsxAdjJfsMqk=.43a90623-9737-4d1b-bfcd-c03a34d961d0@github.com>

On Fri, 16 Sep 2022 12:24:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
>> 
>> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
>> 
>> Running t1-5 with UseSystemMemoryBarrier on.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper accessors for _thread_state

Thumbs up.

I do have to wonder why we had those casts that you removed.

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.org  Sat Sep 17 15:33:57 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Sep 2022 15:33:57 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <FmJAS88jge_JBJWw5qhbr0vh01g2esojLB8XQFKz4RY=.28132b94-4687-45e9-8309-5e4a032ed60f@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
 <FmJAS88jge_JBJWw5qhbr0vh01g2esojLB8XQFKz4RY=.28132b94-4687-45e9-8309-5e4a032ed60f@github.com>
Message-ID: <d4cKVozE4oPLFjmhkAnI7YaIP-IgQ-C2sGhPerwH67k=.82249187-787f-41b2-9774-92499ea92e36@github.com>

On Fri, 16 Sep 2022 14:39:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Can't we do the same in ~ThreadBlockInVMPreprocess() for the blocked transition?

Perhaps, but please use a new RFE/bug for that.

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

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

From zgu at openjdk.org  Sun Sep 18 00:26:42 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 18 Sep 2022 00:26:42 GMT
Subject: RFR: JDK-8292073: NMT: remove unused constructor parameter from
 MallocHeader
In-Reply-To: <PmbX_-yXnBAI8RcIXMZ4WLh3cUwRAefqSM-Ed-bjS28=.805f2767-cb5c-4ac7-b669-7c7ca9a03891@github.com>
References: <PmbX_-yXnBAI8RcIXMZ4WLh3cUwRAefqSM-Ed-bjS28=.805f2767-cb5c-4ac7-b669-7c7ca9a03891@github.com>
Message-ID: <T7LUzoBekGCohsukGRgmiQRLbIl2Nw3wsGlA67ObW8E=.8eaee4c0-328c-4dce-96b9-1c3dc5b4fed6@github.com>

On Fri, 16 Sep 2022 16:13:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial cleanup, removes an unused parameter from `MallocHeader` ctor

LGTM

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

Marked as reviewed by zgu (Reviewer).

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

From jpai at openjdk.org  Sun Sep 18 12:05:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 18 Sep 2022 12:05:10 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
Message-ID: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>

Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?

The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.

Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.

The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.

The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.

Multiple test runs after this change hasn't yet run into the failure.

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

Commit messages:
 - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

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

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

From stuefe at openjdk.org  Sun Sep 18 12:48:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 18 Sep 2022 12:48:17 GMT
Subject: RFR: JDK-8292073: NMT: remove unused constructor parameter from
 MallocHeader
In-Reply-To: <T7LUzoBekGCohsukGRgmiQRLbIl2Nw3wsGlA67ObW8E=.8eaee4c0-328c-4dce-96b9-1c3dc5b4fed6@github.com>
References: <PmbX_-yXnBAI8RcIXMZ4WLh3cUwRAefqSM-Ed-bjS28=.805f2767-cb5c-4ac7-b669-7c7ca9a03891@github.com>
 <T7LUzoBekGCohsukGRgmiQRLbIl2Nw3wsGlA67ObW8E=.8eaee4c0-328c-4dce-96b9-1c3dc5b4fed6@github.com>
Message-ID: <cycIEau2FrGT1gcTfr3iO1Mrckb1CKZ702_KLPCzVZo=.568181a3-bd45-4370-926e-46b8b47b1881@github.com>

On Sun, 18 Sep 2022 00:23:15 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Trivial cleanup, removes an unused parameter from `MallocHeader` ctor
>
> LGTM

Thanks @zhengyu123 !

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

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

From stuefe at openjdk.org  Sun Sep 18 12:48:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 18 Sep 2022 12:48:18 GMT
Subject: Integrated: JDK-8292073: NMT: remove unused constructor parameter from
 MallocHeader
In-Reply-To: <PmbX_-yXnBAI8RcIXMZ4WLh3cUwRAefqSM-Ed-bjS28=.805f2767-cb5c-4ac7-b669-7c7ca9a03891@github.com>
References: <PmbX_-yXnBAI8RcIXMZ4WLh3cUwRAefqSM-Ed-bjS28=.805f2767-cb5c-4ac7-b669-7c7ca9a03891@github.com>
Message-ID: <9cKldXcCFtQQlMonF3av0xXDVF4QwyywzDXtX6Hop5A=.b97931f1-6af0-4bd1-b4cb-6b2a645e609b@github.com>

On Fri, 16 Sep 2022 16:13:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial cleanup, removes an unused parameter from `MallocHeader` ctor

This pull request has now been integrated.

Changeset: b6ff8fa3
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6ff8fa307fd61e342a4926a4fc7be968e964797
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8292073: NMT: remove unused constructor parameter from MallocHeader

Reviewed-by: zgu

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

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

From msheppar at openjdk.org  Sun Sep 18 22:03:38 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Sun, 18 Sep 2022 22:03:38 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <Y3DKnRCbaVIZVsGyoz854SCYW5H1P5Meqj_F4S2GSQs=.15e1ccf9-ed9a-4ef7-b3a1-4373534497b2@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

While the change is reasonable, I?m not sure about your rationale.
The contributing factors to the intermittent failures are due to the flawed ephemeral port allocation strategy, that incurs a race condition to use the selected  ephemeral port within the test before the OS uses it. 
So from the time that the port has been acquired, then released via the autoclose of the serversocket, 
and then reused in the test, it is possible that the OS may have also relocated that ephemeral port.

This change doesn?t alter this race condition.

The are a number of significant attributes to the port allocation strategy:
The port allocation strategy acquires an ephemeral port from the OS while binding it to a ServerSocket. 
The significance of ServerSocket is it surreptitiously sets SO_REUSEADDR socket option on the server socket (Net.socket0() == Java_sun_nio_ch_Net_socket0). The fact that SO_REUSEADDR is set is important in this scenario.

The objective with using SO_REUSEADDR on a serversocket is allow for efficient server restarts due to
a shutdown for whatever reason. With SO_REUSEADDR set the restarting server, which typically uses a well known port, won?t get a BindException, while the port may still be associated with the ?terminating? server i.e. it may not have been fully released by the OS, for general reuse.

Thus, this has a number of favourable consequences with your proposed change, as the address binding is the
same as that used for acquiring the port, so it is essential a ?server restart scenario?, albeit with an
Ephemeral port. As such, there still exists the possibility that the port will be reused by the OS, where
conditions of heavy ephemeral port allocation is occurring.

As such, the change may reduce the rate of intermittent failure, but it won?t solve the issue fully.
There is a possibility that it may increase the rate of failure as many network tests now use
Loopback address rather than the local host address i.e. the primary configured IP address.
This will depend on the load on a test system, and the amount of concurrently executing network tests,
with the corresponding high volume of ephemeral port allocation.

Nonetheless, it is a reasonable change, provided there is no subtle change in test semantics. I think it
will ameliorate the intermittent failures.

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

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

From jpai at openjdk.org  Mon Sep 19 00:44:40 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Sep 2022 00:44:40 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <J-KLEMAmqAnublzUOC1lNA5B9z96uI4dOzF4o9AgKog=.41421633-a84b-4ce8-a24d-902c8b440a00@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Hello Mark, this specific change is merely meant to address the specific test case which is running into this problem. As you note the free port identification logic has and will continue to have the race condition. It will be applicable to all tests that use that utility. This change doesn't propose to do anything for such cases. 

However, in this specific case it wasn't the race condition which was causing the issue. Data that was collected from those failures shows that the issue was because of using the wrong address while trying to bind the free port that was identified. The data collected from these failed runs has been added to the linked JBS issue as a comment to show the port usage.

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

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

From dholmes at openjdk.org  Mon Sep 19 02:26:39 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Sep 2022 02:26:39 GMT
Subject: RFR: JDK-8293466: libjsig should ignore non-modifying sigaction
 calls
In-Reply-To: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
References: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
Message-ID: <uKb87MrD7E9WzWVO3i9t3Lb1hhewZVH4IgdKs4OsZmM=.d3ab1c01-5072-4f9a-b429-4832d76446b2@github.com>

On Sat, 10 Sep 2022 06:15:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Found during code review of [JDK-8292695](https://bugs.openjdk.org/browse/JDK-8292695).
> 
> We have two bugs in libjsig when we install hotspot signal handlers. Relevant code in libjsig:
> 
> 
> int sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {
> <snip>
> 
>   sigused = sigismember(&jvmsigs, sig);
>   if (jvm_signal_installed && sigused) {
>     /* jvm has installed its signal handler for this signal. */
>     /* Save the handler. Don't really install it. */
>     if (oact != NULL) {
>       *oact = sact[sig];
>     }
>     if (act != NULL) {
>       sact[sig] = *act;
>     }
> 
>     signal_unlock();
>     return 0;
>   } else if (jvm_signal_installing) {
>     /* jvm is installing its signal handlers. Install the new
>      * handlers and save the old ones. */
>     res = call_os_sigaction(sig, act, &oldAct);
>     sact[sig] = oldAct;
>     if (oact != NULL) {
>       *oact = oldAct;
>     }
> 
>     /* Record the signals used by jvm. */
>     sigaddset(&jvmsigs, sig);
> 
>     signal_unlock();
>     return res;
>   }
> <snip>
> }
> 
> 
> Bug 1: we change state even if the sigaction call failed
> Bug 2: we change state even if the sigaction call was a non-modifying one (act == NULL)
> 
> The latter is usually no problem since hotspot always calls `sigaction()` in pairs when installing a signal: first with NULL to get the old handler, then with the real handler. But this is not always true. If `AllowUserSignalHandlers` is set, and we find a custom handler is present, we will not override it:
> 
> 
> void set_signal_handler(int sig, bool do_check = true) {
>   // Check for overwrite.
>   struct sigaction oldAct;
>   sigaction(sig, (struct sigaction*)NULL, &oldAct); <<<<< first sigaction call, libjsig now remembers signal as set
> 
>   // Query the current signal handler. Needs to be a separate operation
>   // from installing a new handler since we need to honor AllowUserSignalHandlers.
>   void* oldhand = get_signal_handler(&oldAct);
>   if (!HANDLER_IS_IGN_OR_DFL(oldhand) &&
>       !HANDLER_IS(oldhand, javaSignalHandler)) {
>     if (AllowUserSignalHandlers) {
>       // Do not overwrite; user takes responsibility to forward to us.
>       return;
> 
> 
> That means:
> - we still have the original custom handler in place
> - but we already called sigaction, albeit with NULL, but libjsig now assumes that hotspot installed a handler itself.
> 
> The result is that any further attempts to change the signal handler, whether by hotspot or by user code, will be prevented by libjsig. Any further non-modifying sigaction calls will return the original - still installed - custom handler.
> 
> Admittedly, the error is very exotic. Users would have to set AllowUserSignalHandlers and preload libjsig, and *then* attempt to modify signal handlers after JVM initialization. But it is confusing, and a potential source for other errors. In hotspot, nobody counts on a non-modifying sigaction query changing program state somewhere.
> 
> This seems to be an old bug, I see it in at least JDK 8. Did not look further into the past
> 
> ---
> 
> Tests: Ran the runtime/jsig and the runtime/Thread tests manually.

This seems quite reasonable.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.org  Mon Sep 19 02:37:46 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Sep 2022 02:37:46 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
Message-ID: <Axj_UtoQpnnVwFxZKU8taBaEgOCMA_6oBxACDsTIqNY=.80efa579-651c-4cda-9bd8-270d23266871@github.com>

On Wed, 7 Sep 2022 14:51:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I needed this recently. We print out the signal block mask, which is fine, but more interesting would be the existing block state at the point of the crash/assertion.

This seems okay though may be of limited use if the crash is from a signal as IIRC that in itself will result in various signals getting blocked whilst we remain in the signal-handler context.

Thanks.

src/hotspot/os/posix/signals_posix.cpp line 1418:

> 1416: 
> 1417:   sigset_t thread_sig_mask;
> 1418:   if (::pthread_sigmask(/* ignored */ SIG_BLOCK, NULL, &thread_sig_mask) == 0) {

Nit: no need for `::` scoping (there is one other existing unnecessary use as well you could remove :) ).

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

Marked as reviewed by dholmes (Reviewer).

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

From stuefe at openjdk.org  Mon Sep 19 05:36:39 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Sep 2022 05:36:39 GMT
Subject: RFR: JDK-8293466: libjsig should ignore non-modifying sigaction
 calls
In-Reply-To: <uKb87MrD7E9WzWVO3i9t3Lb1hhewZVH4IgdKs4OsZmM=.d3ab1c01-5072-4f9a-b429-4832d76446b2@github.com>
References: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
 <uKb87MrD7E9WzWVO3i9t3Lb1hhewZVH4IgdKs4OsZmM=.d3ab1c01-5072-4f9a-b429-4832d76446b2@github.com>
Message-ID: <b7AM8DBY7LoSxbZqxrFXxjoSsyFby25hYfRzsjUJNSQ=.a405459f-9be7-4f6b-9800-8b66564b043e@github.com>

On Mon, 19 Sep 2022 02:24:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems quite reasonable.
> 
> Thanks.

Thank you David!

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

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

From stuefe at openjdk.org  Mon Sep 19 05:37:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Sep 2022 05:37:45 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <Axj_UtoQpnnVwFxZKU8taBaEgOCMA_6oBxACDsTIqNY=.80efa579-651c-4cda-9bd8-270d23266871@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
 <Axj_UtoQpnnVwFxZKU8taBaEgOCMA_6oBxACDsTIqNY=.80efa579-651c-4cda-9bd8-270d23266871@github.com>
Message-ID: <iNOdfCHXo62Dp_izDj2hfgaB6v5N45kx7huvN1ZLiuY=.ff9afbe3-5955-421c-aaf3-9400ca785b4b@github.com>

On Mon, 19 Sep 2022 02:33:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems okay though may be of limited use if the crash is from a signal as IIRC that in itself will result in various signals getting blocked whilst we remain in the signal-handler context.

True, but its interesting to know if we block what we think we block :-)

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

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

From stuefe at openjdk.org  Mon Sep 19 05:41:05 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Sep 2022 05:41:05 GMT
Subject: Integrated: JDK-8293466: libjsig should ignore non-modifying sigaction
 calls
In-Reply-To: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
References: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
Message-ID: <ims99wJcbvrgOzbAscmXnT99CZfvkQGaAf9O6FEwx-c=.bdaef629-ff3d-4096-bc2b-b9cf27f536ab@github.com>

On Sat, 10 Sep 2022 06:15:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Found during code review of [JDK-8292695](https://bugs.openjdk.org/browse/JDK-8292695).
> 
> We have two bugs in libjsig when we install hotspot signal handlers. Relevant code in libjsig:
> 
> 
> int sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {
> <snip>
> 
>   sigused = sigismember(&jvmsigs, sig);
>   if (jvm_signal_installed && sigused) {
>     /* jvm has installed its signal handler for this signal. */
>     /* Save the handler. Don't really install it. */
>     if (oact != NULL) {
>       *oact = sact[sig];
>     }
>     if (act != NULL) {
>       sact[sig] = *act;
>     }
> 
>     signal_unlock();
>     return 0;
>   } else if (jvm_signal_installing) {
>     /* jvm is installing its signal handlers. Install the new
>      * handlers and save the old ones. */
>     res = call_os_sigaction(sig, act, &oldAct);
>     sact[sig] = oldAct;
>     if (oact != NULL) {
>       *oact = oldAct;
>     }
> 
>     /* Record the signals used by jvm. */
>     sigaddset(&jvmsigs, sig);
> 
>     signal_unlock();
>     return res;
>   }
> <snip>
> }
> 
> 
> Bug 1: we change state even if the sigaction call failed
> Bug 2: we change state even if the sigaction call was a non-modifying one (act == NULL)
> 
> The latter is usually no problem since hotspot always calls `sigaction()` in pairs when installing a signal: first with NULL to get the old handler, then with the real handler. But this is not always true. If `AllowUserSignalHandlers` is set, and we find a custom handler is present, we will not override it:
> 
> 
> void set_signal_handler(int sig, bool do_check = true) {
>   // Check for overwrite.
>   struct sigaction oldAct;
>   sigaction(sig, (struct sigaction*)NULL, &oldAct); <<<<< first sigaction call, libjsig now remembers signal as set
> 
>   // Query the current signal handler. Needs to be a separate operation
>   // from installing a new handler since we need to honor AllowUserSignalHandlers.
>   void* oldhand = get_signal_handler(&oldAct);
>   if (!HANDLER_IS_IGN_OR_DFL(oldhand) &&
>       !HANDLER_IS(oldhand, javaSignalHandler)) {
>     if (AllowUserSignalHandlers) {
>       // Do not overwrite; user takes responsibility to forward to us.
>       return;
> 
> 
> That means:
> - we still have the original custom handler in place
> - but we already called sigaction, albeit with NULL, but libjsig now assumes that hotspot installed a handler itself.
> 
> The result is that any further attempts to change the signal handler, whether by hotspot or by user code, will be prevented by libjsig. Any further non-modifying sigaction calls will return the original - still installed - custom handler.
> 
> Admittedly, the error is very exotic. Users would have to set AllowUserSignalHandlers and preload libjsig, and *then* attempt to modify signal handlers after JVM initialization. But it is confusing, and a potential source for other errors. In hotspot, nobody counts on a non-modifying sigaction query changing program state somewhere.
> 
> This seems to be an old bug, I see it in at least JDK 8. Did not look further into the past
> 
> ---
> 
> Tests: Ran the runtime/jsig and the runtime/Thread tests manually.

This pull request has now been integrated.

Changeset: b1ed40a8
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b1ed40a87ab357d1b51ac5102bba181f21ffa9b6
Stats:     22 lines in 1 file changed: 14 ins; 3 del; 5 mod

8293466: libjsig should ignore non-modifying sigaction calls

Reviewed-by: manc, dholmes

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

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

From rehn at openjdk.org  Mon Sep 19 05:51:09 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 19 Sep 2022 05:51:09 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
Message-ID: <C4KKFWWI-xwTh2315H5jf6nU6Bplv7IcVxQlMRIGOtA=.ee1d2e44-b002-42e8-9255-0935fe4d69ad@github.com>

On Fri, 16 Sep 2022 12:24:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
>> 
>> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
>> 
>> Running t1-5 with UseSystemMemoryBarrier on.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper accessors for _thread_state

The casts came from the time when the atomics didn't use templates, so it only supported integer types.

TBIVM should not really notice any difference, since it mostly used together with VM Mutex, thus must emit a fence on front edge. As Dan says, do a separate RFE if you like it to be consistent.

Thanks for reviewing!

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

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

From shade at openjdk.org  Mon Sep 19 07:39:42 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 07:39:42 GMT
Subject: RFR: 8293851: hs_err should print more stack in hex dump [v2]
In-Reply-To: <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
 <nLKW_MW4Wf7MzwVfAxx_UaGxAe1qBGyLpVzL-551AXE=.86db9c3d-c1cb-4269-b39f-d3b7740721e9@github.com>
Message-ID: <-6HuapFsyciSq2k1uobvppo6ICdBIyYw7dxyyQJsuyA=.bd1c020f-fda3-4ff3-87f2-43419c9ca4b6@github.com>

On Thu, 15 Sep 2022 15:00:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
>> 
>> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
>> 
>> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
>> 
>> x86_64 hs_err before:
>> 
>> Top of Stack: (sp=0x00007fdab92650b0)
>> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
>> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
>> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
>> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
>> 
>> 
>> x86_64 hs_err after:
>> 
>> Top of Stack: (sp=0x00007f10ccb1d0b0)
>> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
>> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
>> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
>> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
>> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
>> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
>> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
>> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
>> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
>> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
>> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
>> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
>> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
>> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
>> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
>> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
>> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
>> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
>> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
>> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
>> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
>> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
>> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
>> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
>> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
>> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
>> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
>> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
>> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
>> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
>> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
>> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
>> 
>> 
>> Testing:
>>   - [x] Eyeballing ad-hoc crash logs
>>   - [x] Build: linux-x86_64-server-fastdebug
>>   - [x] Build: linux-x86_64-zero-fastdebug
>>   - [x] Build: linux-x86-server-fastdebug
>>   - [x] Cross-build: linux-aarch64-server-fastdebug
>>   - [x] Cross-build: linux-arm-server-fastdebug
>>   - [x] Cross-build: linux-riscv64-server-fastdebug
>>   - [x] Cross-build: linux-s390x-server-fastdebug
>>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>>   - [x] Cross-build: linux-ppc64-server-fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename to print_tos
>  - Drop stack unitsize

All right, I am integrating.

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

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

From shade at openjdk.org  Mon Sep 19 07:41:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 07:41:10 GMT
Subject: Integrated: 8293851: hs_err should print more stack in hex dump
In-Reply-To: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
References: <uUneCuZqe88cjf9gl_-lXMz4GG_ZUw2Zt388epmtjuI=.9e406064-9751-46b1-95b0-6c893577e8ad@github.com>
Message-ID: <RQM1aKzRVzbDern4hna0Ap24MlV9s6xfg2kY2Lnobk4=.4c450c3c-30c1-47e9-8a90-7037e87f7d8a@github.com>

On Thu, 15 Sep 2022 10:44:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8217879](https://bugs.openjdk.org/browse/JDK-8217879), the debugging would be easier if we dump more stack in the hex dump. This is especially convenient when debugging Loom and seeing more of the raw stack in the crash log. Reading farther from current SP is generally safe, since stack banging mechanism provides us with accessible stack at all times for normal SPs. In fact, many platforms already read significantly more stack than x86. 
> 
> We can homogenize the stack printing across all architectures. I believe the stack grows the same way on all supported arches (downwards), so we can read in one direction. Tell me if you still want to make that one selectable.
> 
> As the safeguard, [JDK-8217994](https://bugs.openjdk.org/browse/JDK-8217994) gives us the facility to read the memory much more safely, so we can dump more stack without elevated risk of secondary crash, in case the stack is not readable.
> 
> x86_64 hs_err before:
> 
> Top of Stack: (sp=0x00007fdab92650b0)
> 0x00007fdab92650b0:   00000000ffffffff 00007fdb0c2d5c50
> 0x00007fdab92650c0:   00007fdab9265460 00007fdb12e4a106
> 0x00007fdab92650d0:   0000000000000001 00007fdb0c20e980
> 0x00007fdab92650e0:   0000000000000000 00007fdb0c2ff4c0 
> 
> 
> x86_64 hs_err after:
> 
> Top of Stack: (sp=0x00007f10ccb1d0b0)
> 0x00007f10ccb1d0b0:   00000000ffffffff 00007f11202d5c50
> 0x00007f10ccb1d0c0:   00007f10ccb1d460 00007f11266e4106
> 0x00007f10ccb1d0d0:   0000000000000001 00007f112020e980
> 0x00007f10ccb1d0e0:   0000000000000000 00007f11202ff4c0
> 0x00007f10ccb1d0f0:   00007f112020e980 00007f10ccb1d140
> 0x00007f10ccb1d100:   00007f11202fd4f0 00007f11202ffb80
> 0x00007f10ccb1d110:   00007f11202ffbc0 00007f11202fff68
> 0x00007f10ccb1d120:   00000000000003d8 00007f1000000002
> 0x00007f10ccb1d130:   00007f11202ff4c0 00007f10ccb1d550
> 0x00007f10ccb1d140:   00007f11202fd4f0 0000000300000007
> 0x00007f10ccb1d150:   00007f11202d5c50 00007f112020e980
> 0x00007f10ccb1d160:   00007f10ccb1d740 0000000000000000
> 0x00007f10ccb1d170:   00007f10a80668c0 00007f11ffffffff
> 0x00007f10ccb1d180:   00007f109c00d250 00007f1000000000
> 0x00007f10ccb1d190:   00007f109c00ecd8 00007f10a80404a0
> 0x00007f10ccb1d1a0:   0000000000000000 000000011d001001
> 0x00007f10ccb1d1b0:   0000000000000000 00007f11202ffc20
> 0x00007f10ccb1d1c0:   00007f11202ffbc0 0000000800000000
> 0x00007f10ccb1d1d0:   0000000100000003 0000000000000000
> 0x00007f10ccb1d1e0:   00007f11202ffc68 00007f1000000003
> 0x00007f10ccb1d1f0:   00007f10a803b1d0 0000002000000000
> 0x00007f10ccb1d200:   000000000000003b 0000004100000000
> 0x00007f10ccb1d210:   000000aaffffffff 00007f10ccb1d218
> 0x00007f10ccb1d220:   00000000000001e8 00007f1127d233e6
> 0x00007f10ccb1d230:   00007f110fee5f80 0000000000000000
> 0x00007f10ccb1d240:   00007f110fee5f80 00007f110fef2c50
> 0x00007f10ccb1d250:   00007f10a8040490 00007f10a8040490
> 0x00007f10ccb1d260:   00007f10a8040498 00007f110fee5f80
> 0x00007f10ccb1d270:   00007f1120000001 00007f10ccb1d218
> 0x00007f10ccb1d280:   00007f110fe65f80 0000000000000000
> 0x00007f10ccb1d290:   00007f110fe66051 00007f110fee5b18
> 0x00007f10ccb1d2a0:   00007f10a8040338 00007f10a804034c 
> 
> 
> Testing:
>   - [x] Eyeballing ad-hoc crash logs
>   - [x] Build: linux-x86_64-server-fastdebug
>   - [x] Build: linux-x86_64-zero-fastdebug
>   - [x] Build: linux-x86-server-fastdebug
>   - [x] Cross-build: linux-aarch64-server-fastdebug
>   - [x] Cross-build: linux-arm-server-fastdebug
>   - [x] Cross-build: linux-riscv64-server-fastdebug
>   - [x] Cross-build: linux-s390x-server-fastdebug
>   - [x] Cross-build: linux-ppc64le-server-fastdebug
>   - [x] Cross-build: linux-ppc64-server-fastdebug

This pull request has now been integrated.

Changeset: cbd0688b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbd0688b321ff88a405be4f7929d6862e543ab50
Stats:     41 lines in 13 files changed: 7 ins; 12 del; 22 mod

8293851: hs_err should print more stack in hex dump

Reviewed-by: adinn, stefank

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

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

From mbaesken at openjdk.org  Mon Sep 19 11:17:28 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Sep 2022 11:17:28 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
Message-ID: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>

The 2 methods os::current_thread_cpu_time_info and os::thread_cpu_time_info could be unified across the posix platforms.

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

Commit messages:
 - JDK-8293997

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

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

From tschatzl at openjdk.org  Mon Sep 19 11:32:19 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 19 Sep 2022 11:32:19 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal
Message-ID: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>

Hi all,

  can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.

With this change it shows up as
`   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
which I believe is best.

Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test

Thanks,
  Thomas

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

Commit messages:
 - rename

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

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

From shade at openjdk.org  Mon Sep 19 12:01:43 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 12:01:43 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal
In-Reply-To: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
Message-ID: <d0IJRk_BkOlHaRu3dYDUPyMBF-AWLr_AOlOPcjLQRpE=.c320b05b-8bd9-45a0-9fff-c7389cca87c8@github.com>

On Mon, 19 Sep 2022 11:24:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
> 
> With this change it shows up as
> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
> which I believe is best.
> 
> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
> 
> Thanks,
>   Thomas

I am good with "java" -> "jdk" move, but why are we dropping `L...;`? I would have thought we need to pass the JVM name to `TypeArrayKlass::create_klass`?

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

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

From dholmes at openjdk.org  Mon Sep 19 12:13:44 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Sep 2022 12:13:44 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
Message-ID: <MvwU3iaSnaPMqU_i7Cp-aWAtP75YbMUGjZZXpiRIg8w=.2f12ed25-0abc-4664-b4a9-cd8e8a9cb5fa@github.com>

On Mon, 19 Sep 2022 11:10:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The 2 methods os::current_thread_cpu_time_info and os::thread_cpu_time_info could be unified across the posix platforms.

@MBaesken this has been proposed before but I objected on the basis that the "info" function should be co-located with the actual "time" function, as the former describes the properties of the latter. As long as the time function is in OS specific code then the info function should be too IMO.

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

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

From mdoerr at openjdk.org  Mon Sep 19 12:31:39 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 19 Sep 2022 12:31:39 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr) failed:
 must have PC
Message-ID: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>

JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

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

Commit messages:
 - 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr) failed: must have PC

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

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

From tschatzl at openjdk.org  Mon Sep 19 12:42:49 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 19 Sep 2022 12:42:49 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal
In-Reply-To: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
Message-ID: <B-cJ1p3cxix-GDTjjIDemqUjcWyCdVZ_NcTLwJ6zDaw=.cfbb3609-e275-4280-8991-12b473959c1b@github.com>

On Mon, 19 Sep 2022 11:24:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
> 
> With this change it shows up as
> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
> which I believe is best.
> 
> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
> 
> Thanks,
>   Thomas

The given name does not seem to have any particular requirements in `TypeArrayKlass::create_klass` apart from being unique. So I chose the name to look "best" in the `jmap` output; otherwise it would show that `L...;` there too.
Other classes from `jdk.vm.internal.*` also show up without the `L...;` in the `jmap` output.

The string passed to `TypeArrayKlass:create_klass` for basic types also does not have `L...;` either, it's e.g. `[I`. Only element types of arrays have the `L...;` in jmap histogram, e.g. `[Ljava.util.concurrent.ConcurrentHashMap$Node;`. But this (internal) klass doesn't expose its element type.

So I thought removing the `L...;` would be just fine.

Obviously I'll change the name to whatever is correct.

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

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

From mbaesken at openjdk.org  Mon Sep 19 13:17:45 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Sep 2022 13:17:45 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <MvwU3iaSnaPMqU_i7Cp-aWAtP75YbMUGjZZXpiRIg8w=.2f12ed25-0abc-4664-b4a9-cd8e8a9cb5fa@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
 <MvwU3iaSnaPMqU_i7Cp-aWAtP75YbMUGjZZXpiRIg8w=.2f12ed25-0abc-4664-b4a9-cd8e8a9cb5fa@github.com>
Message-ID: <pjyKTb7l8Bk1AvPiPNrlZtExr3UEKJhE45RKXgj1hOU=.b501d0d0-e48b-478e-ba8f-eda4a460cc7b@github.com>

On Mon, 19 Sep 2022 12:09:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @MBaesken this has been proposed before but I objected on the basis that the "info" function should be co-located with the actual "time" function, as the former describes the properties of the latter. As long as the time function is in OS specific code then the info function should be too IMO.

Hi David,  I wonder about the following   it seems we have just one caller per function , JvmtiEnv::GetCurrentThreadCpuTimerInfo  and JvmtiEnv::GetThreadCpuTimerInfo .
Does it make much sense any more to have the functions at all, we could just move the coding to the callers?

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

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

From tschatzl at openjdk.org  Mon Sep 19 13:49:47 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 19 Sep 2022 13:49:47 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal [v2]
In-Reply-To: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
Message-ID: <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>

> Hi all,
> 
>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
> 
> With this change it shows up as
> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
> which I believe is best.
> 
> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  The FillerArrayKlass name passed to create_klass() needs to have `L...;` after all because of JNI which expects klasses to start with certain characters only

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10336/files
  - new: https://git.openjdk.org/jdk/pull/10336/files/9271a8c0..dfe47467

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

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

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

From tschatzl at openjdk.org  Mon Sep 19 13:49:48 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 19 Sep 2022 13:49:48 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal [v2]
In-Reply-To: <d0IJRk_BkOlHaRu3dYDUPyMBF-AWLr_AOlOPcjLQRpE=.c320b05b-8bd9-45a0-9fff-c7389cca87c8@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
 <d0IJRk_BkOlHaRu3dYDUPyMBF-AWLr_AOlOPcjLQRpE=.c320b05b-8bd9-45a0-9fff-c7389cca87c8@github.com>
Message-ID: <7LMXBJmhiHRtplG0vorguB6CXZJyBBmO1gBWdgq5Zg8=.624629aa-7cc9-4c26-a197-a33c6e73d53a@github.com>

On Mon, 19 Sep 2022 11:59:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The FillerArrayKlass name passed to create_klass() needs to have `L...;` after all because of JNI which expects klasses to start with certain characters only
>
> I am good with "java" -> "jdk" move, but why are we dropping `L...;`? I would have thought we need to pass the JVM name to `TypeArrayKlass::create_klass`?

JNI needs `L...;` in front of the name passed to `TAK::create_klass`. So the name passed there needs to be as suggested by @shipilev.

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

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

From pchilanomate at openjdk.org  Mon Sep 19 14:01:53 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 19 Sep 2022 14:01:53 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
Message-ID: <g9dzPb1UBHjwJxjCPsoeyuvtad0oKEvOSlM_vJDJ8fc=.9c2da7e5-219c-4438-b6ae-150217b2cdeb@github.com>

On Fri, 16 Sep 2022 12:24:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
>> 
>> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
>> 
>> Running t1-5 with UseSystemMemoryBarrier on.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper accessors for _thread_state

Marked as reviewed by pchilanomate (Reviewer).

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

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

From rrich at openjdk.org  Mon Sep 19 14:02:59 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 19 Sep 2022 14:02:59 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v3]
In-Reply-To: <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <-CdoduIsZBNl7Hqje87jdrC9NbAiG4I-lNzsWqTItD4=.7871424a-5d99-4986-b72b-4c187dd5c2a9@github.com>
Message-ID: <-DxdeGR9vtPNmKexha0I0y2MlcqN-1DtUb2J2gDOeHQ=.f29f3f64-abc0-47fa-a268-14133c39efca@github.com>

On Thu, 15 Sep 2022 07:43:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> This fix simply removes the special case for interpreted frames in the shared method `Continuation::continuation_bottom_sender()`. I cannot see a reason for the distinction between interpreted and compiled frames. The shared code reference to `frame::interpreter_frame_last_sp()` is thereby eliminated.
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Only pass the actual sp when calling is_sp_in_continuation()
>  - Merge branch 'master'
>  - Merge branch 'master'
>  - Remove platform dependent method interpreter_frame_last_sp() from shared code

Hi Dean,

I'll answer your questions below but actually I don't think it is necessary to
look into these platform details at all. The platform abstraction layer does not
specify `unextended_sp >= sp`. Consequently the callers of
is_sp_in_continuation() rely on undefined behaviour. The proposed change fixes
this.

Also if ppc64 would be changed (and maybe also aarch64 after
[JDK-8289128](https://bugs.openjdk.org/browse/JDK-8289128)?) to achieve that
unextended_sp always points into the frame then this would be just a property of
the port and, as such, not sufficient.

A dedicated RFE would be needed to establish `unextended_sp >= sp` as part of
the platform abstraction. Shared code should assert the property and it should
be covered by tests. I wouldn't be in favour of such a RFE though. It would limit
the degree of freedom without need.

> Actually, for interpreted --> interpreted, aarch64 and ppc64 seem to do the same trimming. The difference is ppc64 does it in the caller, while aarch64 does it in the callee:
> 
> https://github.com/openjdk/jdk/blob/725f41ffd4b137aef3f83700b4e181e9d93368d4/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1578
> 
> So this would mean for interpreted --> compiled, ppc64 does trimming and aarch64 does not.

I see, thanks.

> I also noticed that on ppc64, the value of unextended_sp for interpreted
> frames in inconsistent. Whether or not it is the "max stack" value depends on
> who calls the frame constructor. Some Loom code and
> sender_for_compiled_frame() sets unextended_sp the same as sp,

On x64 sender_for_compiled_frame() also sets unextended_sp == sp even though
this is not correct if the sender is an interpreted frame. It's not important
because the value is not used. At least it wasn't before Loom.

For the ppc64 Loom port I was forced to construct frames with unextended_sps
similar to x64 (e.g. pointing to the call parameters if interpreted) to satisfy
Loom shared code assumptions. Luckily it worked but IMHO that shared Loom code
breaks the platform abstraction and has to be fixed.

>  while only sender_for_interpreter_frame() uses the "max stack" value.

For good reason because if the sender is compiled then the sender_sp has to be
used as unextended_sp because that's the pointer to find 'stuff' in compiled
frames. If the sender happens to be an interpreted frame then the sender_sp will
be the "max stack" value. It would be really confusing though to use something
else. Especially if doing it only on ppc64 but not aarch64.

> Giving unextended_sp a consistent "canonical" value that is always inside the
> frame, no matter if the callee is interpreted or compiled, seems like it would
> make unextended_sp() valid for is_sp_in_continuation() as well.

Not really as it would still rely on an undefined property which, for instance,
may be invalid on riscv.

Thanks, Richard.

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

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

From shade at openjdk.org  Mon Sep 19 16:11:43 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 16:11:43 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal [v2]
In-Reply-To: <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
 <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>
Message-ID: <Fo54lM5IWlBEbkxvOMkmTmt9V6fFvcaqK8p46fbct9g=.9faee5be-31ed-41ce-baac-d9f73328b305@github.com>

On Mon, 19 Sep 2022 13:49:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
>> 
>> With this change it shows up as
>> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
>> which I believe is best.
>> 
>> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The FillerArrayKlass name passed to create_klass() needs to have `L...;` after all because of JNI which expects klasses to start with certain characters only

Looks fine then!

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

Marked as reviewed by shade (Reviewer).

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

From iklam at openjdk.org  Mon Sep 19 18:34:50 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 19 Sep 2022 18:34:50 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v2]
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <0hxng3R-ZFzWmXuotoVt2KTcYWahCgsxGjACmYxt9LE=.729cd1aa-cd1c-45f7-b7d2-0dabc1d7d05b@github.com>

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @calvinccheung comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10296/files
  - new: https://git.openjdk.org/jdk/pull/10296/files/4eee5962..24b905b3

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

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

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

From cjplummer at openjdk.org  Mon Sep 19 19:01:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 19 Sep 2022 19:01:50 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy
In-Reply-To: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
Message-ID: <gLNoj4RVAv5xs70J4-OUBG2g4u6jHixB-vY5AFvm5IY=.21e639cb-979b-4a1b-b59f-ccf78687ea16@github.com>

On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
> 
> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
> 
> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
> 
> Thanks to @dholmes-ora for finding this bug.

src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 187:

> 185:   }
> 186: 
> 187:   void print_with_childs(outputStream* st, BranchTracker& branchtracker,

I know this isn't part of your changes, but the plural of child is children, not childs. However, I think child_nodes would probably be best here.

src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 320:

> 318:     return (loader_klass() != NULL) && (loader_klass() == target_node->loader_klass()) &&
> 319:            ((loader_name_oop() == NULL && target_node->loader_name_oop() == NULL) ||
> 320:              (::strcmp(loader_name(), target_node->loader_name()) == 0));

This is hard to parse. I think using if/else statements would be cleaner.

test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java line 124:

> 122:         output.shouldContain("      +-- \"Kevin\", ClassLoaderHierarchyTest$TestClassLoader");
> 123:         output.shouldContain("      +-- ClassLoaderHierarchyTest$TestClassLoader");
> 124:         output.shouldContain("      |     +-- \"Bill\", ClassLoaderHierarchyTest$TestClassLoader");

Can you test using one long string, and do the same for each section below? I think embedding \\R as the newline character should work on all platforms. If you run into unforeseen issues, then don't worry about.

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

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

From dholmes at openjdk.org  Mon Sep 19 20:54:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Sep 2022 20:54:45 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
Message-ID: <H8YvWcKI11x2SkP25c2neQ7UdL49pWXvqIawvicFa8Q=.a188a065-12f0-4db8-a460-0cc97b00de09@github.com>

On Mon, 19 Sep 2022 11:10:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The 2 methods os::current_thread_cpu_time_info and os::thread_cpu_time_info could be unified across the posix platforms.

Yes there is only one caller as this is the VM implementation of those JVMTI methods. But the "info" functions describe the properties of the associated "timer/clock" and those are platform specific.

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

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

From xliu at openjdk.org  Mon Sep 19 21:10:28 2022
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 19 Sep 2022 21:10:28 GMT
Subject: RFR: 8294037: Using alias template to unify hashtables in
 AsyncLogWriter
Message-ID: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>

This change is only for clear code. No functional change is intended.

Currently, there are two hashtables. One is this on c-heap.

  using AsyncLogMap = ResourceHashtable<LogFileStreamOutput*,
                          uint32_t,
                          17, /*table_size*/
                          ResourceObj::C_HEAP,
                          mtLogging>;

and the other one is its mirror on ResourceArena. It's not accident. The 2nd one is the snapshot of prior one. 
We use this approach to release lock early. Flushing snapshot doesn't require lock protection and therefore 
won't block logsites.


  ResourceMark rm;
  // Similar to AsyncLogMap but on resource_area
  ResourceHashtable<LogFileStreamOutput*, uint32_t,
                          17/*table_size*/, ResourceObj::RESOURCE_AREA,
                          mtLogging> snapshot;

C++11 has a new feature called [alias template](https://en.cppreference.com/w/cpp/language/type_alias). We can
use this feature to unify two types.

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

Commit messages:
 - 8294037: Using alias template to unify hashtables in AsyncLogWriter

Changes: https://git.openjdk.org/jdk/pull/10350/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10350&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294037
  Stats: 12 lines in 2 files changed: 3 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10350.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10350/head:pull/10350

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

From dholmes at openjdk.org  Mon Sep 19 21:27:53 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Sep 2022 21:27:53 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
Message-ID: <Dk6t68vd4hTNEFJX3NVBs4f8PR_5K8igfJVNvYeFwbY=.c370d664-701e-4cf8-aebf-40bdd1802133@github.com>

On Fri, 9 Sep 2022 08:27:41 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments in test

Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.

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

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

From stuefe at openjdk.org  Tue Sep 20 05:28:55 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Sep 2022 05:28:55 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <Dk6t68vd4hTNEFJX3NVBs4f8PR_5K8igfJVNvYeFwbY=.c370d664-701e-4cf8-aebf-40bdd1802133@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
 <Dk6t68vd4hTNEFJX3NVBs4f8PR_5K8igfJVNvYeFwbY=.c370d664-701e-4cf8-aebf-40bdd1802133@github.com>
Message-ID: <DwmpYkb2Nc1Pm1DN2WnCOli_yyCRqjPeVZDBIkkGkMg=.f06bd645-519e-49c9-b642-3affa0e62179@github.com>

On Mon, 19 Sep 2022 21:23:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.

Hmm, we put a lot of work and time into this solution. While I acknowledge this is a difficult area, so are many others in hotspot which we are not shy of changing. And we did not change the coding on a whim - the proposed solution IMHO is better than the assortment of piled-on hotfixes we had before and dissolves quite a bit of complexity. That makes the code easier to understand and maintain in the long run. @caoman also provided a regression test, so that's covered too.

But if you have concrete misgivings about the proposed solution, let's discuss it.

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

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

From stuefe at openjdk.org  Tue Sep 20 05:37:44 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Sep 2022 05:37:44 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v2]
In-Reply-To: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
Message-ID: <g_njvkGzpw5XvckBGibjEWVUDcqyUqIfvaNUTRTjOKE=.cb851bba-cb63-4d9f-9767-812b1aaec152@github.com>

> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
> 
> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
> 
> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
> 
> Thanks to @dholmes-ora for finding this bug.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  cjplummer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10312/files
  - new: https://git.openjdk.org/jdk/pull/10312/files/0f5de199..224df5fc

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

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

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

From stuefe at openjdk.org  Tue Sep 20 05:37:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Sep 2022 05:37:45 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy
In-Reply-To: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
Message-ID: <rmXtbtccay_Lkxf16Oa2caK9JSptoDIKGtMvsigyoZw=.3408d83b-8e7b-470c-bf69-bcc5a90051b2@github.com>

On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
> 
> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
> 
> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
> 
> Thanks to @dholmes-ora for finding this bug.

Hi @plummercj , thanks for your Review. I worked most of your your feedback.

.. Thomas

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

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

From stuefe at openjdk.org  Tue Sep 20 05:37:48 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Sep 2022 05:37:48 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v2]
In-Reply-To: <gLNoj4RVAv5xs70J4-OUBG2g4u6jHixB-vY5AFvm5IY=.21e639cb-979b-4a1b-b59f-ccf78687ea16@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <gLNoj4RVAv5xs70J4-OUBG2g4u6jHixB-vY5AFvm5IY=.21e639cb-979b-4a1b-b59f-ccf78687ea16@github.com>
Message-ID: <qLujRQ_-tnDV58usAJtxHSWeaMWgRfB0IZqI7h4OuNA=.8979f614-2bfb-47d7-9bce-74be20792893@github.com>

On Mon, 19 Sep 2022 18:45:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cjplummer feedback
>
> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 187:
> 
>> 185:   }
>> 186: 
>> 187:   void print_with_childs(outputStream* st, BranchTracker& branchtracker,
> 
> I know this isn't part of your changes, but the plural of child is children, not childs. However, I think child_nodes would probably be best here.

Fixed

> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 320:
> 
>> 318:     return (loader_klass() != NULL) && (loader_klass() == target_node->loader_klass()) &&
>> 319:            ((loader_name_oop() == NULL && target_node->loader_name_oop() == NULL) ||
>> 320:              (::strcmp(loader_name(), target_node->loader_name()) == 0));
> 
> This is hard to parse. I think using if/else statements would be cleaner.

Fixed

> test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java line 124:
> 
>> 122:         output.shouldContain("      +-- \"Kevin\", ClassLoaderHierarchyTest$TestClassLoader");
>> 123:         output.shouldContain("      +-- ClassLoaderHierarchyTest$TestClassLoader");
>> 124:         output.shouldContain("      |     +-- \"Bill\", ClassLoaderHierarchyTest$TestClassLoader");
> 
> Can you test using one long string, and do the same for each section below? I think embedding \\R as the newline character should work on all platforms. If you run into unforeseen issues, then don't worry about.

I'd prefer to leave it this way. I tried what you suggested before, but the output can contain trailing spaces in the branchwork of the tree - that is a byproduct of the indentation writer (the class writing the branches) and not easy to fix. I wanted the test to be somewhat tolerant against minor future changes in how the tree is printed.

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

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

From dholmes at openjdk.org  Tue Sep 20 06:14:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 06:14:45 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v5]
In-Reply-To: <y-voNU0VMgxQpG7qvSL_2YNUOfiiuwwfsW-mm86NZHg=.4c3258ee-88cf-43ea-91a2-194b3d98dcf6@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com>
 <zhmKyAlUo5gpadIIxuOgaa3nszIKDtmfsuwd0sJTd4A=.85d1ff75-1554-420b-ba99-4f6ebd1847e6@github.com>
 <Bb5HWPlCZG6yJEbX3sa0MReCmBdZtYGnyh6vcQ39zSU=.9be9fc24-433a-4070-bcd9-16542168e5d2@github.com>
 <VRpa6-opEssOIzap8PejKkq4H_f9ByVchcsCHyUNyqQ=.3c1f67aa-4a6d-49bd-ad39-3f04628e7671@github.com>
 <y-voNU0VMgxQpG7qvSL_2YNUOfiiuwwfsW-mm86NZHg=.4c3258ee-88cf-43ea-91a2-194b3d98dcf6@github.com>
Message-ID: <sO0C9QP2GEiUdRTIBXiX9Evjln0OQa9KHwq0Ngy8ts0=.bdf647db-17e8-46b6-857b-baa7d48416e1@github.com>

On Thu, 8 Sep 2022 16:13:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>>To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL.
>> 
>> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this.
>> 
>> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets.
>
>> >To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL.
>> 
>> 
>> 
>> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this.
>> 
>> 
>> 
>> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets.
> 
> The early initialization of UL at lib load time is certainly a pain. 
> 
> But there are other things too, other code running before initialisation, and then there is the case of non-attached threads and signal handling, etc.
> 
> I would be happy if this primitive was usable with Thread.current == Null. Otherwise you limit the future usefulness, and whatever code people use this lock in will also not be usable in these corner cases. 
> 
> If it does not cost too much complexity.

Any use by non-attached threads is potentially problematic as they can prevent safepoints etc. I don't think we should be using a RWL in any code that might be executed by a non-attached thread. None of our locking code is async-signal-safe so using it from signal handlers should also be avoided.

Early initialization of UL should be examined more closely. Anything initialized before we have threads doesn't need locking by definition, so if we structure the code/api correctly we won't encounter locks. That may mean clearly separating initialization code from similar modification code e.g. a growable data structure will need a lock in the grow method, but we don't then use the grow method from the constructor.

But lets see what @jdksjolen comes up with here.

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

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

From mbaesken at openjdk.org  Tue Sep 20 07:11:30 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Sep 2022 07:11:30 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
Message-ID: <TMEQ_uGmsI3JykRnE8S66hi-E1g1kzk2BontBHy0OGU=.88081b27-20dc-4e68-8072-7637a2d7ac91@github.com>

On Mon, 19 Sep 2022 11:10:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The 2 methods os::current_thread_cpu_time_info and os::thread_cpu_time_info could be unified across the posix platforms.

Hi David, in theory the info functions could be platform specific; in practise currently they are all the same on posix AND Windows, see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L4642 .

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

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

From rehn at openjdk.org  Tue Sep 20 08:40:42 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 20 Sep 2022 08:40:42 GMT
Subject: RFR: 8293922: Extend barrier-less Java thread transitions to
 native transitions [v2]
In-Reply-To: <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
 <ak9h0-wKCs7yfyzGTWIn6Zo9Cesjl063JWBgh3kaTSI=.6163f407-d3fd-46a5-af0c-6edca9fd752c@github.com>
Message-ID: <v82dgiAIHdEnof3vMMoINmDe8-nTsRAJthASgnzQPuc=.f0c8a1e8-31ad-4f35-ac90-9a38e6dbb564@github.com>

On Fri, 16 Sep 2022 12:24:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
>> 
>> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
>> 
>> Running t1-5 with UseSystemMemoryBarrier on.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper accessors for _thread_state

Thanks!

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

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

From rehn at openjdk.org  Tue Sep 20 08:44:56 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 20 Sep 2022 08:44:56 GMT
Subject: Integrated: 8293922: Extend barrier-less Java thread transitions to
 native transitions
In-Reply-To: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
References: <JUilOXQ6oLV0oMFWkSZU8W7HZ91iGRIvttWqm6wgH7c=.b22f1005-3581-4d27-a362-e421421059e5@github.com>
Message-ID: <b3TZ9Tf1TMT4W4dKw6IjkR89vMltlLhtij-iHA7TwmU=.dbf5325a-ab18-4530-8aa5-4aca53a262f5@github.com>

On Fri, 16 Sep 2022 10:01:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.
> 
> Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).
> 
> Running t1-5 with UseSystemMemoryBarrier on.

This pull request has now been integrated.

Changeset: 1b496064
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b496064bf1c5078b6f753282771996e0d1b94d6
Stats:     10 lines in 2 files changed: 5 ins; 0 del; 5 mod

8293922: Extend barrier-less Java thread transitions to native transitions

Reviewed-by: mdoerr, pchilanomate, dcubed

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

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

From jsjolen at openjdk.org  Tue Sep 20 12:48:40 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 20 Sep 2022 12:48:40 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
In-Reply-To: <64dBk9q9MnvwD6Zh4FTp8ASWNhBCKUwEO8bfA2vwYf8=.888197a2-3d6e-4407-81e7-267546c747dc@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <64dBk9q9MnvwD6Zh4FTp8ASWNhBCKUwEO8bfA2vwYf8=.888197a2-3d6e-4407-81e7-267546c747dc@github.com>
Message-ID: <54gu66M3RMXXgSJ59A4PK9MJSZl3edv1zm_CprRdWgU=.e6451425-3b77-4598-ad77-f27a61bcb255@github.com>

On Fri, 16 Sep 2022 16:20:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > but it might change how UL works before VM start up
> 
> This is a bit vague :)
> 
> How exactly does UL initialization change? Does it move? If yes, what happens if we log now before initialization?

That's fair enough :-).

There are 3 times for UL:
- (a) logging does nothing
- (b) severe enough logging is redirected to stdout
- (c) UL is initialized according to user supplied options (including being disabled).

And this is a timeline showing how initialization has changed between before and after this change:


Time -->
    static init                main     LC::init            Args::parse                             VM init done
|---------------------|------------------|-----------------|--------------------------------------|
         (a)                         (b)                                    (c)
|-------------------- |------------------------------------|--------------------------------------| Old way
                    (a)                         (b)                         (c)
|----------------------------------------|-----------------|---------------------------------------| New way


So the time where (a) holds has lengthened, and the time that (b) holds has been shortened.

I'd like to entirely remove (b) in a future PR, because certain applications depend on them controlling stdout/stderr completely. Furthermore, I haven't been able to show that the JVM even depends on (b) being available.

Does this illustration make sense?

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

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

From jsjolen at openjdk.org  Tue Sep 20 13:02:48 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 20 Sep 2022 13:02:48 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
In-Reply-To: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
Message-ID: <-j1u6M5WD_qfaiRwfUGjJLcl_VTwW9aluWy3cUwgrbk=.e8519b85-3169-4ddc-865d-d55e55ba5ad1@github.com>

On Fri, 16 Sep 2022 12:22:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.
> 
> Tier 2 and 3 tests are currently running, all green so far.
> 
> Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873

Some of these files haven't had their copyright years updated.

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

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

From kcr at openjdk.org  Tue Sep 20 14:26:45 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Sep 2022 14:26:45 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <_W8bK_pIfXVi4f1Yca9LzMu3OGyaUGnHmHjPv2EKM14=.a3586b95-ea5e-4f24-9a73-9f19c92cc887@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

How does the test fail? Does it actually find and load the "mockfx" classes, but subsequently fail? Or is it unable to patch/upgrade the javafx.graphics module with the "mockfx" classes?

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

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

From cjplummer at openjdk.org  Tue Sep 20 18:06:58 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 Sep 2022 18:06:58 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v2]
In-Reply-To: <qLujRQ_-tnDV58usAJtxHSWeaMWgRfB0IZqI7h4OuNA=.8979f614-2bfb-47d7-9bce-74be20792893@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <gLNoj4RVAv5xs70J4-OUBG2g4u6jHixB-vY5AFvm5IY=.21e639cb-979b-4a1b-b59f-ccf78687ea16@github.com>
 <qLujRQ_-tnDV58usAJtxHSWeaMWgRfB0IZqI7h4OuNA=.8979f614-2bfb-47d7-9bce-74be20792893@github.com>
Message-ID: <7xGhj4G6VBdSVEF1omY1zgAZa3DqSRmeK6QTly9xrTU=.a4a60db6-3c1d-4b1e-9bb5-e591c6d1a5c2@github.com>

On Tue, 20 Sep 2022 05:29:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 187:
>> 
>>> 185:   }
>>> 186: 
>>> 187:   void print_with_childs(outputStream* st, BranchTracker& branchtracker,
>> 
>> I know this isn't part of your changes, but the plural of child is children, not childs. However, I think child_nodes would probably be best here.
>
> Fixed

It looks like there are a couple more references to "childs" still present.

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

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

From dholmes at openjdk.org  Wed Sep 21 01:25:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 01:25:42 GMT
Subject: RFR: 8293872: Make runtime/Thread/ThreadCountLimit.java more
 robust
In-Reply-To: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
References: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
Message-ID: <jlMGFJ4Mw9rDHgfTiErmXmRSHnElxpvf-fIKAa3Ym1o=.975463a9-06f4-4168-b383-e758a8b9620e@github.com>

On Thu, 15 Sep 2022 17:06:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am seeing this failure frequently on linux-x86:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
> ...
> stdout:
> [1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
> [1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
> # An error report file with more information is saved as:
> # /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
> [2.019s][warning][os ] Loading hsdis library failed
> 
> 
> It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.
> 
> I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.
> 
> Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.
> 
> After [JDK-8255450](https://bugs.openjdk.org/browse/JDK-8255450), this test still runs in tier2.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, affected test in 100 repetitions (all passed!)
>  - [ ]  Linux x86_64 fastdebug, affected test in 100 repetitions

This seems fine. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From lzhai at openjdk.org  Wed Sep 21 01:41:52 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 01:41:52 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <_W8bK_pIfXVi4f1Yca9LzMu3OGyaUGnHmHjPv2EKM14=.a3586b95-ea5e-4f24-9a73-9f19c92cc887@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <_W8bK_pIfXVi4f1Yca9LzMu3OGyaUGnHmHjPv2EKM14=.a3586b95-ea5e-4f24-9a73-9f19c92cc887@github.com>
Message-ID: <igJUOJMgFDEsZi3LbkzMC8KeIkWZ-JoRvYcyQmEytCk=.4d0bb809-49c7-4952-b331-cdeadfc37adb@github.com>

On Tue, 20 Sep 2022 14:23:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293910: Try --upgrade-module-path and --patch-module but still failed
>
> How does the test fail? Does it actually find and load the "mockfx" classes, but subsequently fail? Or is it unable to patch/upgrade the javafx.graphics module with the "mockfx" classes?

Hi @kevinrushforth 

I updated the testcase to check whether or not FX is part of jdk:


        // Check whether or not FX is part of jdk
        try {
            fxClass = Class.forName(FX_MARKER_CLASS);
        } catch (ClassNotFoundException ex) {
            // do nothing
        }
        if (fxClass != null) {
            System.out.println("JavaFX modules included in the JDK");
        }


And tried to `--upgrade-module-path` in the `doFxCompile` when JavaFX modules included in the JDK:


    static void doFxCompile(String...compilerArgs) {
        if (fxClass == null) {
            compileFXModule();
        }

        List<String> fxCompilerArgs = new ArrayList<>();
        if (fxClass == null) {
            fxCompilerArgs.add("--module-path=" + MODULE_DIR);
        } else {
            fxCompilerArgs.add("--upgrade-module-path=" + IMPORT_MODULE_DIR);
        }
        fxCompilerArgs.add("--add-modules=javafx.graphics");
        fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
        compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
    }


Also tried `--patch-module` in the `doFxExec`:


    static TestResult doFxExec(String...cmds) {
        List<String> fxCmds = new ArrayList<>();
        fxCmds.addAll(Arrays.asList(cmds));
        if (fxClass == null) {
            fxCmds.add(1, "--module-path=" + MODULE_DIR);
            fxCmds.add(2, "--add-modules=javafx.graphics");
        } else {
            fxCmds.add(1, "--upgrade-module-path=" + IMPORT_MODULE_DIR);
            fxCmds.add(2, "--patch-module=javafx.graphics=" + IMPORT_MODULE_DIR + "/javafx.graphics.jmod");
        }
        return doExec(fxCmds.toArray(new String[fxCmds.size()]));
    }


But it might be unable to patch/upgrade the javafx.graphics module with the "mockfx" classes:


STDOUT:
_____________________________________________
test# 1-  Main method: public static void main(String[] args) { launch(args); }
Main-Class: helloworld.HelloWorld
renaming fxtest.jar to testBasicFXApp_useCP_noJAC-1-fxtest.jar
FAIL: testBasicFXApp_useCP_noJAC:1 : test with helloworld.HelloWorld
Test static void FXLauncherTest.testBasicFXApp() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testBasicFXApp_useCP_noJAC:1
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testBasicFXApp(FXLauncherTest.java:311)
	at FXLauncherTest.testBasicFXApp(FXLauncherTest.java:266)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
_____________________________________________
test# 2-  Main method: public static void main(String[] args) { launch(args); }
Main-Class: helloworld.ExtHello
renaming fxtest.jar to testExtendFXApp_useCP_noJAC-2-fxtest.jar
FAIL: testExtendFXApp_useCP_noJAC:2 : test with helloworld.ExtHello
Test static void FXLauncherTest.testExtendFXApp() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testExtendFXApp_useCP_noJAC:2
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testExtendFXApp(FXLauncherTest.java:369)
	at FXLauncherTest.testExtendFXApp(FXLauncherTest.java:323)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
_____________________________________________
test# 3: abort on missing Main-Class
JavaFX-Application-Class: helloworld.HelloWorld
renaming fxtest.jar to testMissingMC-3-fxtest.jar
FAIL: testMissingMC:3 : test with helloworld.HelloWorld
Test static void FXLauncherTest.testMissingMC() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testMissingMC:3
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testMissingMC(FXLauncherTest.java:399)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
_____________________________________________
test# 4: test for erroneous jfxrt.jar loading
Main-Class: helloworld.HelloJava
renaming fxtest.jar to testExtraneousJars_useCP-4-fxtest.jar
FAIL: testExtraneousJars_useCP:4 : test with helloworld.HelloJava
Test static void FXLauncherTest.testExtraneousJars() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testExtraneousJars_useCP:4
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testExtraneousJars(FXLauncherTest.java:453)
	at FXLauncherTest.testExtraneousJars(FXLauncherTest.java:410)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
Total: Passed: 0, Failed 4
STDERR:
Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -cp /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar helloworld.HelloWorld one two 

###TestError###: test did not return 0 exit value
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  Error occurred during initialization of boot layer
  java.lang.module.FindException: Unable to compute the hash of module javafx.graphics
++++Test Stack Trace++++
java.lang.Throwable: current stack of the test
  TestHelper.doExec(TestHelper.java:476)
  TestHelper.doExec(TestHelper.java:437)
  FXLauncherTest.doFxExec(FXLauncherTest.java:252)
  FXLauncherTest.testBasicFXApp(FXLauncherTest.java:292)
  FXLauncherTest.testBasicFXApp(FXLauncherTest.java:266)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  TestHelper.run(TestHelper.java:200)
  FXLauncherTest.main(FXLauncherTest.java:469)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
  java.base/java.lang.Thread.run(Thread.java:1589)
++++End of Test Info++++

Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -cp /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar helloworld.ExtHello one two 

###TestError###: test did not return 0 exit value
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  Error occurred during initialization of boot layer
  java.lang.module.FindException: Unable to compute the hash of module javafx.graphics
++++Test Stack Trace++++
java.lang.Throwable: current stack of the test
  TestHelper.doExec(TestHelper.java:476)
  TestHelper.doExec(TestHelper.java:437)
  FXLauncherTest.doFxExec(FXLauncherTest.java:252)
  FXLauncherTest.testExtendFXApp(FXLauncherTest.java:350)
  FXLauncherTest.testExtendFXApp(FXLauncherTest.java:323)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  TestHelper.run(TestHelper.java:200)
  FXLauncherTest.main(FXLauncherTest.java:469)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
  java.base/java.lang.Thread.run(Thread.java:1589)
++++End of Test Info++++

ERROR: launcher did not abort properly
Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -jar /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar one two 

###TestError###: string <no main manifest attribute> not found
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  Error occurred during initialization of boot layer
  java.lang.module.FindException: Unable to compute the hash of module javafx.graphics
++++Test Stack Trace++++
java.lang.Throwable: current stack of the test
  TestHelper.doExec(TestHelper.java:476)
  TestHelper.doExec(TestHelper.java:437)
  FXLauncherTest.doFxExec(FXLauncherTest.java:252)
  FXLauncherTest.testMissingMC(FXLauncherTest.java:390)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  TestHelper.run(TestHelper.java:200)
  FXLauncherTest.main(FXLauncherTest.java:469)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
  java.base/java.lang.Thread.run(Thread.java:1589)
++++End of Test Info++++

Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -verbose:class -cp /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar helloworld.HelloJava one two 

###TestError###: test did not return 0 exit value
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  [0.016s][info][class,load] java.lang.Object source: shared objects file
  [0.019s][info][class,load] java.io.Serializable source: shared objects file
...


Thanks,
Leslie Zhai

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

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

From dholmes at openjdk.org  Wed Sep 21 01:43:36 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 01:43:36 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal [v2]
In-Reply-To: <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
 <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>
Message-ID: <8hsKUOreaHm804N22VxhDZ1wjRNxYQgNSfLJDOGCh4g=.f4912f6e-a4d8-49fe-9575-80644a79f9d3@github.com>

On Mon, 19 Sep 2022 13:49:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
>> 
>> With this change it shows up as
>> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
>> which I believe is best.
>> 
>> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The FillerArrayKlass name passed to create_klass() needs to have `L...;` after all because of JNI which expects klasses to start with certain characters only

Looks good.

I'm surprised this didn't cause any kind of problem.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.org  Wed Sep 21 02:35:44 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 02:35:44 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v2]
In-Reply-To: <g_njvkGzpw5XvckBGibjEWVUDcqyUqIfvaNUTRTjOKE=.cb851bba-cb63-4d9f-9767-812b1aaec152@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <g_njvkGzpw5XvckBGibjEWVUDcqyUqIfvaNUTRTjOKE=.cb851bba-cb63-4d9f-9767-812b1aaec152@github.com>
Message-ID: <0goVLP540GYUPvShbPPV7bm2Jgg_5s_kU8b2hTOD7RA=.bedcc542-225a-45e3-bce3-522fc358da3e@github.com>

On Tue, 20 Sep 2022 05:37:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
>> 
>> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
>> 
>> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
>> 
>> Thanks to @dholmes-ora for finding this bug.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cjplummer feedback

Hi Thomas,

Generally this seems fine - but one issue below.

Thanks.

src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 209:

> 207:         st->print(" \"%s\",", the_loader_name);
> 208:       }
> 209:       st->print(" %s", the_loader_class_name);

`the_loader_class_name` could be NULL here. You need to change `loader_class_name()` t return "??" like the original code uses.

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

Changes requested by dholmes (Reviewer).

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

From xliu at openjdk.org  Wed Sep 21 02:41:12 2022
From: xliu at openjdk.org (Xin Liu)
Date: Wed, 21 Sep 2022 02:41:12 GMT
Subject: RFR: 8294075: gtest/AsyncLogGtest crashes with SEGV
Message-ID: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>

In order to test "drop messages scenario", I replace the serving buffers with shrunk buffers(1k).
This is done by RAII class 'AsyncLogWriter::BufferUpdater'. There is a race condition between test and AsyncLog thread. 
The race condition exhibits when AsyncLog thread is still processing `buffer_staging` but test thread deletes it in dtor of BufferUpdater. 

This patch issues AsyncLogWriter::flush() before dtor of BufferUpdater. buffers are reverted only when pending messages have all been handled.

I test TEST="jtreg:hotspot/jtreg/gtest/AsyncLogGtest.java" 100 times and never see race condition.

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

Commit messages:
 - 8294075: gtest/AsyncLogGtest crashes with SEGV

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

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

From dholmes at openjdk.org  Wed Sep 21 04:10:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 04:10:00 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
Message-ID: <7UD5dqbukFK545xhRuxOBCwzrSszgmk4Lu_O1rC6bFQ=.c1e927a6-7f0e-4df4-8187-947556b4a023@github.com>

On Mon, 19 Sep 2022 11:10:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The 2 methods os::current_thread_cpu_time_info and os::thread_cpu_time_info could be unified across the posix platforms.

Yes in practice they are currently the same, but that doesn't change anything in my view. The info functions belong with the thing they describe.

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

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

From stuefe at openjdk.org  Wed Sep 21 06:41:50 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 06:41:50 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v2]
In-Reply-To: <0goVLP540GYUPvShbPPV7bm2Jgg_5s_kU8b2hTOD7RA=.bedcc542-225a-45e3-bce3-522fc358da3e@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <g_njvkGzpw5XvckBGibjEWVUDcqyUqIfvaNUTRTjOKE=.cb851bba-cb63-4d9f-9767-812b1aaec152@github.com>
 <0goVLP540GYUPvShbPPV7bm2Jgg_5s_kU8b2hTOD7RA=.bedcc542-225a-45e3-bce3-522fc358da3e@github.com>
Message-ID: <cDqXTAmoNlVOUIO9-INXfIHs_blaTHF80k5yjIh-q-8=.e0a3c293-8ac0-431e-928c-9b2734d2dc54@github.com>

On Wed, 21 Sep 2022 02:26:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cjplummer feedback
>
> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 209:
> 
>> 207:         st->print(" \"%s\",", the_loader_name);
>> 208:       }
>> 209:       st->print(" %s", the_loader_class_name);
> 
> `the_loader_class_name` could be NULL here. You need to change `loader_class_name()` t return "??" like the original code uses.

Good catch. We never encounter this because Klass can only be null for the bootstrap loader, which is handled in a different branch. I'll fix it.

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

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

From stuefe at openjdk.org  Wed Sep 21 06:51:56 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 06:51:56 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v3]
In-Reply-To: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
Message-ID: <CTB-y4lJh0rmSHKCxad-ux75Qt8qcqq7IVasCP69nd4=.15f6cf9f-9165-48dd-8e37-9163d80eeaa2@github.com>

> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
> 
> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
> 
> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
> 
> Thanks to @dholmes-ora for finding this bug.

Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision:

 - Fix test error in GHAs
 - feedback dholmes
 - childs->children

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10312/files
  - new: https://git.openjdk.org/jdk/pull/10312/files/224df5fc..3510ddcb

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

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

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

From stuefe at openjdk.org  Wed Sep 21 06:51:57 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 06:51:57 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy
In-Reply-To: <rmXtbtccay_Lkxf16Oa2caK9JSptoDIKGtMvsigyoZw=.3408d83b-8e7b-470c-bf69-bcc5a90051b2@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <rmXtbtccay_Lkxf16Oa2caK9JSptoDIKGtMvsigyoZw=.3408d83b-8e7b-470c-bf69-bcc5a90051b2@github.com>
Message-ID: <OPNUqpXgZoUxVY9r5zdg4KnrS_Im8034xFIZkmIXJsI=.7479c341-d3d2-4e24-ab80-ec32eba236b7@github.com>

On Tue, 20 Sep 2022 05:33:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi @plummercj , thanks for your Review. I worked most of your your feedback.
> 
> .. Thomas

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

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

From stuefe at openjdk.org  Wed Sep 21 06:51:57 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 06:51:57 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v2]
In-Reply-To: <g_njvkGzpw5XvckBGibjEWVUDcqyUqIfvaNUTRTjOKE=.cb851bba-cb63-4d9f-9767-812b1aaec152@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <g_njvkGzpw5XvckBGibjEWVUDcqyUqIfvaNUTRTjOKE=.cb851bba-cb63-4d9f-9767-812b1aaec152@github.com>
Message-ID: <jhmqYxXX-ckR_fw_sMWKKXXNi10-fuVYfG3-lXgKNVM=.eb03826d-5b5a-4396-90f0-4a2bc125e505@github.com>

On Tue, 20 Sep 2022 05:37:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
>> 
>> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
>> 
>> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
>> 
>> Thanks to @dholmes-ora for finding this bug.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cjplummer feedback

- Fixed all remaining occurrences of "childs"
- Fixed possible segfault when printing class name for bootstrap loader
- Fixed GHAs (apparently we don't have a MainWrapper class when executing jtreg in GHAs, so I cannot parse for it)

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

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

From dholmes at openjdk.org  Wed Sep 21 07:02:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 07:02:58 GMT
Subject: RFR: 8294075: gtest/AsyncLogGtest crashes with SEGV
In-Reply-To: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
References: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
Message-ID: <aYfXMETrrGmsNoqHiCxd7uuM_yQ-2ZVuxkP6ssDpcr4=.3ae89418-3905-4752-b291-ba1381439b91@github.com>

On Wed, 21 Sep 2022 02:34:03 GMT, Xin Liu <xliu at openjdk.org> wrote:

> In order to test "drop messages scenario", I replace the serving buffers with shrunk buffers(1k).
> This is done by RAII class 'AsyncLogWriter::BufferUpdater'. There is a race condition between test and AsyncLog thread. 
> The race condition exhibits when AsyncLog thread is still processing `buffer_staging` but test thread deletes it in dtor of BufferUpdater. 
> 
> This patch issues AsyncLogWriter::flush() before dtor of BufferUpdater. buffers are reverted only when pending messages have all been handled.
> 
> I test TEST="jtreg:hotspot/jtreg/gtest/AsyncLogGtest.java" 100 times and never see race condition.

Based on the explanation of the bug this fix seems reasonable.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From rrich at openjdk.org  Wed Sep 21 07:04:08 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 21 Sep 2022 07:04:08 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
Message-ID: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>

> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
> 
> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
> 
> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
> 
> This fix changes the callers of is_sp_in_continuation()
> 
> ```c++
> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>   return entry->entry_sp() > sp;
> }
> 
> 
> to pass the actual sp. This is correct because the following is true on all platforms:
> 
> ```c++
> a.sp() > E->entry_sp() > b.sp() > c.sp()
> 
> 
> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
> 
> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
> 
> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Remove `Unimplemented` definitions of interpreter_frame_last_sp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9411/files
  - new: https://git.openjdk.org/jdk/pull/9411/files/fdb14090..14c97290

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

  Stats: 21 lines in 6 files changed: 0 ins; 21 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9411.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9411/head:pull/9411

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

From alanb at openjdk.org  Wed Sep 21 07:13:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:13:55 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

The --patch-module option is used to override or add classes/resources in the module, it doesn't override the module definition. I see you tried --upgrade-module-path too but you've set the value to IMPORT_MODULE_DIR and it's not clear what this means in this test.

Can you try this, I think this should do what you want:


--- a/test/jdk/tools/launcher/FXLauncherTest.java
+++ b/test/jdk/tools/launcher/FXLauncherTest.java
@@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
         compileFXModule();
 
         List<String> fxCompilerArgs = new ArrayList<>();
-        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
+        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
         fxCompilerArgs.add("--add-modules=javafx.graphics");
         fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
         compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
@@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
     static TestResult doFxExec(String...cmds) {
         List<String> fxCmds = new ArrayList<>();
         fxCmds.addAll(Arrays.asList(cmds));
-        fxCmds.add(1, "--module-path=" + MODULE_DIR);
+        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
         fxCmds.add(2, "--add-modules=javafx.graphics");
         return doExec(fxCmds.toArray(new String[fxCmds.size()]));
     }
@@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
     }
 
     public static void main(String... args) throws Exception {
-
-        // Ensure that FX is not part of jdk
-        Class<?> fxClass = null;
-        try {
-            fxClass = Class.forName(FX_MARKER_CLASS);
-        } catch (ClassNotFoundException ex) {
-            // do nothing
-        }
-        if (fxClass != null) {
-            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
-        }
-
         FXLauncherTest fxt = new FXLauncherTest();
         fxt.run(args);
         if (testExitValue > 0) {

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

PR: https://git.openjdk.org/jdk/pull/10299

From lzhai at openjdk.org  Wed Sep 21 07:44:45 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 07:44:45 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
Message-ID: <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>

On Wed, 21 Sep 2022 07:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293910: Try --upgrade-module-path and --patch-module but still failed
>
> The --patch-module option is used to override or add classes/resources in the module, it doesn't override the module definition. I see you tried --upgrade-module-path too but you've set the value to IMPORT_MODULE_DIR and it's not clear what this means in this test.
> 
> Can you try this, I think this should do what you want:
> 
> 
> --- a/test/jdk/tools/launcher/FXLauncherTest.java
> +++ b/test/jdk/tools/launcher/FXLauncherTest.java
> @@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
>          compileFXModule();
>  
>          List<String> fxCompilerArgs = new ArrayList<>();
> -        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
> +        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
>          fxCompilerArgs.add("--add-modules=javafx.graphics");
>          fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
>          compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
> @@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
>      static TestResult doFxExec(String...cmds) {
>          List<String> fxCmds = new ArrayList<>();
>          fxCmds.addAll(Arrays.asList(cmds));
> -        fxCmds.add(1, "--module-path=" + MODULE_DIR);
> +        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
>          fxCmds.add(2, "--add-modules=javafx.graphics");
>          return doExec(fxCmds.toArray(new String[fxCmds.size()]));
>      }
> @@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
>      }
>  
>      public static void main(String... args) throws Exception {
> -
> -        // Ensure that FX is not part of jdk
> -        Class<?> fxClass = null;
> -        try {
> -            fxClass = Class.forName(FX_MARKER_CLASS);
> -        } catch (ClassNotFoundException ex) {
> -            // do nothing
> -        }
> -        if (fxClass != null) {
> -            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
> -        }
> -
>          FXLauncherTest fxt = new FXLauncherTest();
>          fxt.run(args);
>          if (testExitValue > 0) {

Hi @AlanBateman 

Debug patch:


diff --git a/test/jdk/tools/launcher/FXLauncherTest.java b/test/jdk/tools/launcher/FXLauncherTest.java
index 9cc4b5aea98..33c3e2788ad 100644
--- a/test/jdk/tools/launcher/FXLauncherTest.java
+++ b/test/jdk/tools/launcher/FXLauncherTest.java
@@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
         compileFXModule();
 
         List<String> fxCompilerArgs = new ArrayList<>();
-        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
+        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
         fxCompilerArgs.add("--add-modules=javafx.graphics");
         fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
         compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
@@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
     static TestResult doFxExec(String...cmds) {
         List<String> fxCmds = new ArrayList<>();
         fxCmds.addAll(Arrays.asList(cmds));
-        fxCmds.add(1, "--module-path=" + MODULE_DIR);
+        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
         fxCmds.add(2, "--add-modules=javafx.graphics");
         return doExec(fxCmds.toArray(new String[fxCmds.size()]));
     }
@@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
     }
 
     public static void main(String... args) throws Exception {
-
-        // Ensure that FX is not part of jdk
-        Class<?> fxClass = null;
-        try {
-            fxClass = Class.forName(FX_MARKER_CLASS);
-        } catch (ClassNotFoundException ex) {
-            // do nothing
-        }
-        if (fxClass != null) {
-            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
-        }
-
         FXLauncherTest fxt = new FXLauncherTest();
         fxt.run(args);
         if (testExitValue > 0) {


Still failed:  [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From dholmes at openjdk.org  Wed Sep 21 07:47:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 07:47:54 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v3]
In-Reply-To: <CTB-y4lJh0rmSHKCxad-ux75Qt8qcqq7IVasCP69nd4=.15f6cf9f-9165-48dd-8e37-9163d80eeaa2@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <CTB-y4lJh0rmSHKCxad-ux75Qt8qcqq7IVasCP69nd4=.15f6cf9f-9165-48dd-8e37-9163d80eeaa2@github.com>
Message-ID: <ACan46YZJThgpRs8aPwvmQw5o0-e7XFnaYEjLa5JQxw=.f0d40862-7a2b-48dd-8eae-f9e88fdd64c7@github.com>

On Wed, 21 Sep 2022 06:51:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
>> 
>> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
>> 
>> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
>> 
>> Thanks to @dholmes-ora for finding this bug.
>
> Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix test error in GHAs
>  - feedback dholmes
>  - childs->children

Nothing further from me. Thanks!

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10312

From lzhai at openjdk.org  Wed Sep 21 07:48:35 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 07:48:35 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
Message-ID: <93Z70fHZVluqyZp5lKkJG8Qe55zPYKCEdTfgmJMV6xU=.13428b6b-9396-4e0c-b890-56817a21ae50@github.com>

On Wed, 21 Sep 2022 07:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> but you've set the value to IMPORT_MODULE_DIR and it's not clear what this means in this test

I just want to try the imported javafx modules:


--patch-module=javafx.graphics=build/linux-loongarch64-server-fastdebug/images/jdk/jmods/javafx.graphics.jmod

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From alanb at openjdk.org  Wed Sep 21 07:48:37 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:48:37 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <pVbQSMCMqSvuQaoI-qJUPNRwpawwvH-hgjTebjCytKQ=.dd60966c-4b03-4719-a663-2a81fdfe4104@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

I've created JDK-8294093 to track changing ReadSingleImportMetaData (in Modules.gmk) to ignore the mapping in build.properties. If nothing else, that will avoid surprises that will otherwise arise if you run jlink to create a run-time image that includes the javafx.* modules; when you run jlink then it does not map unknown modules to the boot or platform class loader so they will be mapped to the application class loader.

The other aspect to this is whether javafx.* modules should be upgradable. The build adds the imported modules PLATFORM_MODULES but not UPGRADEABLE_PLATFORM_MODULES so this means they will be treated as if they are strongly coupled with the platform/JDK modules and hashed, which probably isn't right here.

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From mbaesken at openjdk.org  Wed Sep 21 07:49:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Sep 2022 07:49:56 GMT
Subject: RFR: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <7UD5dqbukFK545xhRuxOBCwzrSszgmk4Lu_O1rC6bFQ=.c1e927a6-7f0e-4df4-8187-947556b4a023@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
 <7UD5dqbukFK545xhRuxOBCwzrSszgmk4Lu_O1rC6bFQ=.c1e927a6-7f0e-4df4-8187-947556b4a023@github.com>
Message-ID: <XpsfTmy4bBKPq-9LmAuxfK3YpDv_6IqO-9R-_6uZrmY=.e8c3cf19-f554-414f-8eb3-8eb5592b97a3@github.com>

On Wed, 21 Sep 2022 04:07:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Yes in practice they are currently the same, but that doesn't change anything in my view. The info functions belong with the thing they describe.

okay then we'll leave it as it is !

-------------

PR: https://git.openjdk.org/jdk/pull/10335

From mbaesken at openjdk.org  Wed Sep 21 07:49:58 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Sep 2022 07:49:58 GMT
Subject: Withdrawn: JDK-8293997: Unify os::current_thread_cpu_time_info and
 os::thread_cpu_time_info
In-Reply-To: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
References: <gimfuwHRKTbOm5AbWsmdxfP_0Mfix2lVYlCw4U5WEak=.272a334e-dd8e-4d72-8436-3b7ed28f53b9@github.com>
Message-ID: <cCO-V_yve5tjd71oLOChlcM8bJH_0MHhN1G-xGVFlr0=.e8b407ec-f2bf-4861-aa8b-328a45d1fa5d@github.com>

On Mon, 19 Sep 2022 11:10:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The 2 methods os::current_thread_cpu_time_info and os::thread_cpu_time_info could be unified across the posix platforms.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10335

From tschatzl at openjdk.org  Wed Sep 21 07:58:48 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 21 Sep 2022 07:58:48 GMT
Subject: RFR: 8294000: Filler array klass should be in jdk/vm/internal,
 not in java/vm/internal [v2]
In-Reply-To: <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
 <zyiivh0yEXXzBtgvWhyUsCwXgwWDY2s6zLKDINj700U=.16306735-a51a-49d3-8666-192a05790b5c@github.com>
Message-ID: <BoWVz1YpZPJtyvVb-khm6pFKn0_VbothpmukvEkMXvI=.05c4f080-a227-4b03-8acd-edbeb1b54c9a@github.com>

On Mon, 19 Sep 2022 13:49:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
>> 
>> With this change it shows up as
>> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
>> which I believe is best.
>> 
>> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The FillerArrayKlass name passed to create_klass() needs to have `L...;` after all because of JNI which expects klasses to start with certain characters only

Fwiw, I also did a tier1-5 run with the latest change that passed.

Thanks @shipilev @dholmes-ora for your reviews

-------------

PR: https://git.openjdk.org/jdk/pull/10336

From alanb at openjdk.org  Wed Sep 21 08:00:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 08:00:44 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
 <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
Message-ID: <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>

On Wed, 21 Sep 2022 07:42:29 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Still failed: [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)

You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add

   UPGRADEABLE_PLATFORM_MODULES += $1

This will add the names of the imported modules to the list of upgradeable modules and should mean they are not hashed.

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From lzhai at openjdk.org  Wed Sep 21 08:00:44 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 08:00:44 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
 <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
 <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
Message-ID: <BYsEf2SHnwj49eNqN5fEAxdv1QGhgYJIQygSvlMYwr4=.e90a1e85-78ea-4054-b1ef-37ddb6fe789e@github.com>

On Wed, 21 Sep 2022 07:56:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @AlanBateman 
>> 
>> Debug patch:
>> 
>> 
>> diff --git a/test/jdk/tools/launcher/FXLauncherTest.java b/test/jdk/tools/launcher/FXLauncherTest.java
>> index 9cc4b5aea98..33c3e2788ad 100644
>> --- a/test/jdk/tools/launcher/FXLauncherTest.java
>> +++ b/test/jdk/tools/launcher/FXLauncherTest.java
>> @@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
>>          compileFXModule();
>>  
>>          List<String> fxCompilerArgs = new ArrayList<>();
>> -        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
>> +        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
>>          fxCompilerArgs.add("--add-modules=javafx.graphics");
>>          fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
>>          compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
>> @@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
>>      static TestResult doFxExec(String...cmds) {
>>          List<String> fxCmds = new ArrayList<>();
>>          fxCmds.addAll(Arrays.asList(cmds));
>> -        fxCmds.add(1, "--module-path=" + MODULE_DIR);
>> +        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
>>          fxCmds.add(2, "--add-modules=javafx.graphics");
>>          return doExec(fxCmds.toArray(new String[fxCmds.size()]));
>>      }
>> @@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
>>      }
>>  
>>      public static void main(String... args) throws Exception {
>> -
>> -        // Ensure that FX is not part of jdk
>> -        Class<?> fxClass = null;
>> -        try {
>> -            fxClass = Class.forName(FX_MARKER_CLASS);
>> -        } catch (ClassNotFoundException ex) {
>> -            // do nothing
>> -        }
>> -        if (fxClass != null) {
>> -            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
>> -        }
>> -
>>          FXLauncherTest fxt = new FXLauncherTest();
>>          fxt.run(args);
>>          if (testExitValue > 0) {
>> 
>> 
>> Still failed:  [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
>> 
>> Thanks,
>> Leslie Zhai
>
>> Still failed: [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
> 
> You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add
> 
>    UPGRADEABLE_PLATFORM_MODULES += $1
> 
> This will add the names of the imported modules to the list of upgradeable modules and should mean they are not hashed.

Hi @AlanBateman 

> I've created JDK-8294093 to track changing ReadSingleImportMetaData (in Modules.gmk) to ignore the mapping in build.properties

Thanks for your report!

So 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx could be fixed too.

> --with-import-modules option was used in JDK 9/10 for co-bundling JavaFX with the JDK. It seems this configure option is still in use, by some.

Yes, @dumasun use it :)

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From tschatzl at openjdk.org  Wed Sep 21 08:01:37 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 21 Sep 2022 08:01:37 GMT
Subject: Integrated: 8294000: Filler array klass should be in jdk/vm/internal, 
 not in java/vm/internal
In-Reply-To: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
References: <Ep1sAJwXjhipYi1OXTd5R85yj2fQyT6ybs2M9XUG58I=.777cd0cc-7ac4-46b7-b7bc-f06403145322@github.com>
Message-ID: <AaUfbUzMDhaFfKIAwg_z-Fh1nn_GBR2ZlMLGoeNl034=.a4880606-4aa6-438f-8ccd-0344d129c162@github.com>

On Mon, 19 Sep 2022 11:24:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for the move of the internal filler array klass from `java/vm/internal/` to `jdk/vm/internal` - I noticed that typo in some recent `jmap` dump. All internal klasses are in the `jdk.` package... idk how this slipped through the original change.
> 
> With this change it shows up as
> `   2:           428       13291728  jdk.internal.vm.FillerArray (java.base at 20-internal)`
> which I believe is best.
> 
> Testing: local compilation, checking `jmap` output for instances of this klass directly, the `gc/TestFillerObjectInstantiation.java` jtreg test
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 8ecdaa68
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ecdaa68111f2e060a3f46a5cf6f2ba95c9ebad1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8294000: Filler array klass should be in jdk/vm/internal, not in java/vm/internal

Reviewed-by: shade, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/10336

From lzhai at openjdk.org  Wed Sep 21 08:46:09 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 08:46:09 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
 <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
 <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
Message-ID: <pfGdbojtkG_eyNHmsM5Ec_CIWWYTLBD6a8troCBOZd8=.2dd3f459-e92e-4d75-8d47-b8b5329d225a@github.com>

On Wed, 21 Sep 2022 07:56:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @AlanBateman 
>> 
>> Debug patch:
>> 
>> 
>> diff --git a/test/jdk/tools/launcher/FXLauncherTest.java b/test/jdk/tools/launcher/FXLauncherTest.java
>> index 9cc4b5aea98..33c3e2788ad 100644
>> --- a/test/jdk/tools/launcher/FXLauncherTest.java
>> +++ b/test/jdk/tools/launcher/FXLauncherTest.java
>> @@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
>>          compileFXModule();
>>  
>>          List<String> fxCompilerArgs = new ArrayList<>();
>> -        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
>> +        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
>>          fxCompilerArgs.add("--add-modules=javafx.graphics");
>>          fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
>>          compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
>> @@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
>>      static TestResult doFxExec(String...cmds) {
>>          List<String> fxCmds = new ArrayList<>();
>>          fxCmds.addAll(Arrays.asList(cmds));
>> -        fxCmds.add(1, "--module-path=" + MODULE_DIR);
>> +        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
>>          fxCmds.add(2, "--add-modules=javafx.graphics");
>>          return doExec(fxCmds.toArray(new String[fxCmds.size()]));
>>      }
>> @@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
>>      }
>>  
>>      public static void main(String... args) throws Exception {
>> -
>> -        // Ensure that FX is not part of jdk
>> -        Class<?> fxClass = null;
>> -        try {
>> -            fxClass = Class.forName(FX_MARKER_CLASS);
>> -        } catch (ClassNotFoundException ex) {
>> -            // do nothing
>> -        }
>> -        if (fxClass != null) {
>> -            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
>> -        }
>> -
>>          FXLauncherTest fxt = new FXLauncherTest();
>>          fxt.run(args);
>>          if (testExitValue > 0) {
>> 
>> 
>> Still failed:  [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
>> 
>> Thanks,
>> Leslie Zhai
>
>> Still failed: [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
> 
> You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add
> 
>    UPGRADEABLE_PLATFORM_MODULES += $1
> 
> This will add the names of the imported modules to the list of upgradeable modules and should mean they are not hashed.

Hi @AlanBateman 

> You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add
> 
> UPGRADEABLE_PLATFORM_MODULES += $1

debug patch correct?


diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
index 0eb0fb2ddc1..3431384e168 100644
--- a/make/common/Modules.gmk
+++ b/make/common/Modules.gmk
@@ -272,6 +272,7 @@ FindModuleLegalSrcDirs = \
 
 # Param 1 - Name of module
 define ReadSingleImportMetaData
+    UPGRADEABLE_PLATFORM_MODULES += $1
     ifneq ($$(wildcard $(IMPORT_MODULES_MAKE)/$$(strip $1)/build.properties), )
       classloader :=
       include_in_jre :=


Quoted from JDK-8294093:

> --with-import-modules option was used in JDK 9/10 for co-bundling JavaFX with the JDK. It seems this configure option is still in use, by some.

BTW, how to release JavaFX and JDK together? or just release them seperately?

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From shade at openjdk.org  Wed Sep 21 09:00:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Sep 2022 09:00:10 GMT
Subject: RFR: 8293872: Make runtime/Thread/ThreadCountLimit.java more
 robust
In-Reply-To: <jlMGFJ4Mw9rDHgfTiErmXmRSHnElxpvf-fIKAa3Ym1o=.975463a9-06f4-4168-b383-e758a8b9620e@github.com>
References: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
 <jlMGFJ4Mw9rDHgfTiErmXmRSHnElxpvf-fIKAa3Ym1o=.975463a9-06f4-4168-b383-e758a8b9620e@github.com>
Message-ID: <Bqyq7MaaAap7fld47mnHPNYUVvuROANr2NzM0NT6y0I=.328a17a7-3e5b-477d-8f8a-d42e6ee9d695@github.com>

On Wed, 21 Sep 2022 01:22:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems fine. Thanks.

Thanks! Can I have another review?

-------------

PR: https://git.openjdk.org/jdk/pull/10290

From jsjolen at openjdk.org  Wed Sep 21 09:03:44 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 21 Sep 2022 09:03:44 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
Message-ID: <j0ueWTRzfxodxtV03kVOXFWM3TcLCC7C9AnUHbikUSI=.522ebcd7-6c4a-4296-9588-5417ba14eb7e@github.com>

On Wed, 7 Sep 2022 14:51:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I needed this recently. We print out the signal block mask, which is fine, but more interesting would be the existing block state at the point of the crash/assertion.

This LGTM. It fails tier1 tests because it doesn't include the commit that problem lists runtime/os/TestTracePageSizes.java on linux-x64. Merging to master should fix that issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10199

From sgehwolf at openjdk.org  Wed Sep 21 09:39:47 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Sep 2022 09:39:47 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
Message-ID: <aZOIvEIs1iWYeRZ_ZnCuGLBH8l-9qEhNXjkQR2NrfWE=.4a27a777-6bc6-4b31-81fb-eddadb9c47a3@github.com>

On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
>> 
>> 
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
>> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
>> 
>> 
>> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
>> 
>> Testing:
>> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
>> - [x] added tests fail before, pass after the product fix.
>> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
>> - [x] GHA all pass.
>> 
>> Please review! Many thanks in advance.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

Anyone willing to review this? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From shade at openjdk.org  Wed Sep 21 10:41:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Sep 2022 10:41:35 GMT
Subject: RFR: 8294075: gtest/AsyncLogGtest crashes with SEGV
In-Reply-To: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
References: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
Message-ID: <eSBzTQPP4PvD8N4prJqB6Ts778PD0ZnFTURA4nSkAfk=.21fc33b7-3070-4c5d-92ba-7d31b059cbc4@github.com>

On Wed, 21 Sep 2022 02:34:03 GMT, Xin Liu <xliu at openjdk.org> wrote:

> In order to test "drop messages scenario", I replace the serving buffers with shrunk buffers(1k).
> This is done by RAII class 'AsyncLogWriter::BufferUpdater'. There is a race condition between test and AsyncLog thread. 
> The race condition exhibits when AsyncLog thread is still processing `buffer_staging` but test thread deletes it in dtor of BufferUpdater. 
> 
> This patch issues AsyncLogWriter::flush() before dtor of BufferUpdater. buffers are reverted only when pending messages have all been handled.
> 
> I test TEST="jtreg:hotspot/jtreg/gtest/AsyncLogGtest.java" 100 times and never see race condition.

Yes, seems reasonable.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10367

From stuefe at openjdk.org  Wed Sep 21 10:58:53 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 10:58:53 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <j0ueWTRzfxodxtV03kVOXFWM3TcLCC7C9AnUHbikUSI=.522ebcd7-6c4a-4296-9588-5417ba14eb7e@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
 <j0ueWTRzfxodxtV03kVOXFWM3TcLCC7C9AnUHbikUSI=.522ebcd7-6c4a-4296-9588-5417ba14eb7e@github.com>
Message-ID: <mONJOjUNrMPZoIfDTDuuQ1YDOVTYsd1nF32-986Ef4g=.09d89952-f6a8-49ac-bc30-5a43f4b5cf80@github.com>

On Wed, 21 Sep 2022 09:01:39 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> 



> This LGTM. It fails tier1 tests because it doesn't include the commit that problem lists runtime/os/TestTracePageSizes.java on linux-x64. Merging to master should fix that issue.

Thanks @jdksjolen ! Mind hitting the approve button?

-------------

PR: https://git.openjdk.org/jdk/pull/10199

From jsjolen at openjdk.org  Wed Sep 21 11:24:50 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 21 Sep 2022 11:24:50 GMT
Subject: RFR: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
Message-ID: <ZzzyHU4XZfFN_Mn6eGttIYbl4e0PtxSohrg0MtPb0PI=.997f934f-ed5d-4e45-b37c-ea307969e355@github.com>

On Wed, 7 Sep 2022 14:51:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I needed this recently. We print out the signal block mask, which is fine, but more interesting would be the existing block state at the point of the crash/assertion.

Marked as reviewed by jsjolen (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/10199

From duke at openjdk.org  Wed Sep 21 11:38:36 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 21 Sep 2022 11:38:36 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v5]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/e22d35c5..1149de31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=03-04

  Stats: 25 lines in 1 file changed: 2 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Wed Sep 21 11:38:36 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 21 Sep 2022 11:38:36 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <djedmAC0dHkHyeGxras2oHpdXMeY7EyXTYDyOnlPLTM=.eee0e269-cc45-4e90-8b15-ff7deae342bd@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
 <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
 <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>
 <djedmAC0dHkHyeGxras2oHpdXMeY7EyXTYDyOnlPLTM=.eee0e269-cc45-4e90-8b15-ff7deae342bd@github.com>
Message-ID: <RBrk4R7jjhHLRBtueFeaODft1E7Cin2B1xbG_JleOuI=.26944ee7-7d14-4963-ac83-698ad87a4b60@github.com>

On Fri, 16 Sep 2022 16:19:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Extract to a byte array with the appropriate charset and then HexFormat the bytearray.
>> 
>> 
>>     var SysPropHexVal = HexFormat.of().formatHex(sysPropVal.getBytes(StandardCharsets.UTF_16));
>
> Thanks, Roger. You beat me to it ?

Thank you, I fixed it. In addition, since the return value of formatHex is four digits, I fixed the second argument passed to execTest to match that format.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From stuefe at openjdk.org  Wed Sep 21 12:10:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 12:10:09 GMT
Subject: Integrated: JDK-8293493: Signal Handlers printout should show signal
 block state
In-Reply-To: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
References: <89PiOrnpo2zXB_DmzmlmYG9a4pEw_h6nkYdShQoEooo=.669ea3cf-bc1b-414c-a80d-8ff762eda6ea@github.com>
Message-ID: <MS9XPwWPY0ZRVw3t3PyDF3BSaG1kma0TJ6IFIoQLSIg=.9e809a60-b6f3-4910-94ac-47018698c09c@github.com>

On Wed, 7 Sep 2022 14:51:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I needed this recently. We print out the signal block mask, which is fine, but more interesting would be the existing block state at the point of the crash/assertion.

This pull request has now been integrated.

Changeset: d14e96d9
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d14e96d9701dae951aa365029f58afb6687a646a
Stats:     6 lines in 1 file changed: 5 ins; 1 del; 0 mod

8293493: Signal Handlers printout should show signal block state

Reviewed-by: dholmes, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/10199

From coleenp at openjdk.org  Wed Sep 21 13:46:43 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Sep 2022 13:46:43 GMT
Subject: RFR: 8294037: Using alias template to unify hashtables in
 AsyncLogWriter
In-Reply-To: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
References: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
Message-ID: <TyZHsGrdqoRwqi4jMvjHvPxEvWFzaGv7pxodGkqYgtg=.71fbb0e1-eeaa-4e82-8297-16e24fec8d89@github.com>

On Mon, 19 Sep 2022 21:02:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This change is only for clear code. No functional change is intended.
> 
> Currently, there are two hashtables. One is this on c-heap.
> 
>   using AsyncLogMap = ResourceHashtable<LogFileStreamOutput*,
>                           uint32_t,
>                           17, /*table_size*/
>                           ResourceObj::C_HEAP,
>                           mtLogging>;
> 
> and the other one is its mirror on ResourceArena. It's not accident. The 2nd one is the snapshot of prior one. 
> We use this approach to release lock early. Flushing snapshot doesn't require lock protection and therefore 
> won't block logsites.
> 
> 
>   ResourceMark rm;
>   // Similar to AsyncLogMap but on resource_area
>   ResourceHashtable<LogFileStreamOutput*, uint32_t,
>                           17/*table_size*/, ResourceObj::RESOURCE_AREA,
>                           mtLogging> snapshot;
> 
> C++11 has a new feature called [alias template](https://en.cppreference.com/w/cpp/language/type_alias). We can
> use this feature to unify two types.

Marked as reviewed by coleenp (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10350

From iklam at openjdk.org  Wed Sep 21 15:21:28 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 Sep 2022 15:21:28 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <fJT84WvTh7rulSPm5kIMuBY9QV03xEiw7AWb3t17Wkc=.f2a047e8-1b10-4284-a1d0-54f4d2698964@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

The fix looks reasonable to me.

There's a potential error case, if `parent` is not a directory. However, this should lead to an exception later inside `Files.newOutputStream(jarfile)`, so I think it's OK to not check for this.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10266

From alanb at openjdk.org  Wed Sep 21 15:28:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 15:28:15 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <XqYmY8rmtmGDKBpyBkaty9D8_Axe3KJ7N4dCtd_FuqM=.753567c2-70cc-4902-9808-8efa007c6b7e@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

I see Ioi has approved the change but I don't think we should put this workaround into the test library. The issue here is that Files.createDirectories should work like mkdir -p when there are sym links in the tree. Jai is experimenting with a fix to that.

-------------

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10266

From iklam at openjdk.org  Wed Sep 21 15:36:21 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 Sep 2022 15:36:21 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <YId_n7sZfownuHpLtp7iC1FDTx9A4mzZ-eSQC40pilQ=.5c1e223f-3625-4a67-88d2-e099f3604946@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

Withdraw my approval per Alan's comment.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10266

From cjplummer at openjdk.org  Wed Sep 21 16:36:29 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Sep 2022 16:36:29 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v3]
In-Reply-To: <CTB-y4lJh0rmSHKCxad-ux75Qt8qcqq7IVasCP69nd4=.15f6cf9f-9165-48dd-8e37-9163d80eeaa2@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <CTB-y4lJh0rmSHKCxad-ux75Qt8qcqq7IVasCP69nd4=.15f6cf9f-9165-48dd-8e37-9163d80eeaa2@github.com>
Message-ID: <0l9zlblzDGyK8ov4IFf2X5vrvNLD6kfeoyQ846nw7vg=.0dcd0e6b-dd7b-44d2-b71f-516462260154@github.com>

On Wed, 21 Sep 2022 06:51:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
>> 
>> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
>> 
>> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
>> 
>> Thanks to @dholmes-ora for finding this bug.
>
> Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix test error in GHAs
>  - feedback dholmes
>  - childs->children

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10312

From coleenp at openjdk.org  Wed Sep 21 16:41:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Sep 2022 16:41:25 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v2]
In-Reply-To: <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
 <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>
Message-ID: <RbxKfqXKI8kJXrgOjtWL7QH0vMaRVjKyxsKqm_WDCJw=.83a62e39-7dd2-45c6-9631-11e042057b46@github.com>

On Thu, 15 Sep 2022 21:43:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this fix which involves:
>> 
>> - acquire the `Module_lock` before calling `modules_do`;
>> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
>> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
>> 
>> Passed tiers 1 - 3 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of the _total_count field

Looks great.  Thanks for fixing this.  Can you add in moduleEntry.cpp in both modules_do function an assert that the Module_lock is held.  The other modules_do has the assert at a higher level so nothing will trigger it.  The modules_do() that this calls now will not fail the assert.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10291

From naoto at openjdk.org  Wed Sep 21 16:52:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Sep 2022 16:52:45 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v5]
In-Reply-To: <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>
Message-ID: <Ijaev_hEXN91s0kyh3Wi_XwQ3WsGlEB7We1OnNppuko=.7f2ef9d8-a45e-41c1-9f3b-ba05e2cb4855@github.com>

On Wed, 21 Sep 2022 11:38:36 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

Looks good. Please restore the newline at the end before integrating the changes

test/jdk/tools/launcher/I18NArgTest.java line 152:

> 150:         }
> 151:     }
> 152: }

Nit: don't remove the newline at the end

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9389

From stuefe at openjdk.org  Wed Sep 21 17:09:16 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 17:09:16 GMT
Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy [v3]
In-Reply-To: <0l9zlblzDGyK8ov4IFf2X5vrvNLD6kfeoyQ846nw7vg=.0dcd0e6b-dd7b-44d2-b71f-516462260154@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
 <CTB-y4lJh0rmSHKCxad-ux75Qt8qcqq7IVasCP69nd4=.15f6cf9f-9165-48dd-8e37-9163d80eeaa2@github.com>
 <0l9zlblzDGyK8ov4IFf2X5vrvNLD6kfeoyQ846nw7vg=.0dcd0e6b-dd7b-44d2-b71f-516462260154@github.com>
Message-ID: <KsTCV0obzuzkqaeIIeZTLg8qUV7svSl18-yJ0MOD0II=.843dc75f-ad9f-45cf-ae4d-a4d253aa24e9@github.com>

On Wed, 21 Sep 2022 16:32:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix test error in GHAs
>>  - feedback dholmes
>>  - childs->children
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks @plummercj and @dholmes-ora .

-------------

PR: https://git.openjdk.org/jdk/pull/10312

From stuefe at openjdk.org  Wed Sep 21 17:10:43 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Sep 2022 17:10:43 GMT
Subject: Integrated: JDK-8293156: Dcmd VM.classloaders fails to print the full
 hierarchy
In-Reply-To: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
References: <xJb7QuCMeBfIeAR48ULY-4pNjar6Lpm8w_lQpklgCB0=.f6d91f11-6fca-4021-8227-57f7f309d06e@github.com>
Message-ID: <Kn8N-Q9VH-ETa1ENW_YV_UuZpa6H6bZc8ZnVfLwx5rU=.bbd6c72c-6563-4eeb-88eb-630088fb9b32@github.com>

On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd.
> 
> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader.
> 
> Also, the tests were expanded to test the display of empty loaders and empty parent loaders.
> 
> Thanks to @dholmes-ora for finding this bug.

This pull request has now been integrated.

Changeset: c6be2cd3
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6be2cd347fc07dcc0da56acf40fc7a005119f09
Stats:     157 lines in 2 files changed: 103 ins; 21 del; 33 mod

8293156: Dcmd VM.classloaders fails to print the full hierarchy

Reviewed-by: dholmes, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/10312

From xliu at openjdk.org  Wed Sep 21 17:23:13 2022
From: xliu at openjdk.org (Xin Liu)
Date: Wed, 21 Sep 2022 17:23:13 GMT
Subject: RFR: 8294075: gtest/AsyncLogGtest crashes with SEGV
In-Reply-To: <aYfXMETrrGmsNoqHiCxd7uuM_yQ-2ZVuxkP6ssDpcr4=.3ae89418-3905-4752-b291-ba1381439b91@github.com>
References: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
 <aYfXMETrrGmsNoqHiCxd7uuM_yQ-2ZVuxkP6ssDpcr4=.3ae89418-3905-4752-b291-ba1381439b91@github.com>
Message-ID: <RxoBomkD7MlTlVAK3GChdAHMPHz6DeixS6ZK8OezUoI=.cd7ee003-48aa-4319-ae39-c063fbd2de19@github.com>

On Wed, 21 Sep 2022 06:59:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In order to test "drop messages scenario", I replace the serving buffers with shrunk buffers(1k).
>> This is done by RAII class 'AsyncLogWriter::BufferUpdater'. There is a race condition between test and AsyncLog thread. 
>> The race condition exhibits when AsyncLog thread is still processing `buffer_staging` but test thread deletes it in dtor of BufferUpdater. 
>> 
>> This patch issues AsyncLogWriter::flush() before dtor of BufferUpdater. buffers are reverted only when pending messages have all been handled.
>> 
>> I test TEST="jtreg:hotspot/jtreg/gtest/AsyncLogGtest.java" 100 times and never see race condition.
>
> Based on the explanation of the bug this fix seems reasonable.
> 
> Thanks.

hi, @dholmes-ora, 
Do you want to have a trial run of this patch or we just integrate it?

-------------

PR: https://git.openjdk.org/jdk/pull/10367

From ccheung at openjdk.org  Wed Sep 21 18:50:17 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 21 Sep 2022 18:50:17 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v2]
In-Reply-To: <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
 <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>
Message-ID: <eOSlWZTVrzNYSS_eyUEZDHslkKzo4HxwlUWOE-yEp3k=.abf0dd46-8441-465a-9259-319d4ee97b54@github.com>

On Thu, 15 Sep 2022 21:43:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this fix which involves:
>> 
>> - acquire the `Module_lock` before calling `modules_do`;
>> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
>> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
>> 
>> Passed tiers 1 - 3 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of the _total_count field

Hi Coleen,

Thanks for your review.

I've added assert in moduleEntry.cpp as follows:


diff --git a/src/hotspot/share/classfile/moduleEntry.cpp b/src/hotspot/share/classfile/moduleEntry.cpp
index a85c8f41145..f12f63ba2e5 100644
--- a/src/hotspot/share/classfile/moduleEntry.cpp
+++ b/src/hotspot/share/classfile/moduleEntry.cpp
@@ -694,6 +694,7 @@ void ModuleEntryTable::modules_do(void f(ModuleEntry*)) {
   auto do_f = [&] (const SymbolHandle& key, ModuleEntry*& entry) {
     f(entry);
   };
+  assert_lock_strong(Module_lock);
   _table.iterate_all(do_f);
 }
 
@@ -701,6 +702,7 @@ void ModuleEntryTable::modules_do(ModuleClosure* closure) {
   auto do_f = [&] (const SymbolHandle& key, ModuleEntry*& entry) {
     closure->do_module(entry);
   };
+  assert_lock_strong(Module_lock);
   _table.iterate_all(do_f);
 }

I'll run some mach5 testing before integrating the fix.

-------------

PR: https://git.openjdk.org/jdk/pull/10291

From dlong at openjdk.org  Wed Sep 21 22:37:16 2022
From: dlong at openjdk.org (Dean Long)
Date: Wed, 21 Sep 2022 22:37:16 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
Message-ID: <sUqIK2Pee3D9tq08fI2F0d1g8ns90lqXyH1ZvNHEv5M=.b929f07c-c942-4606-85f1-6ee767e91e00@github.com>

On Wed, 21 Sep 2022 07:04:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
>> 
>> This fix changes the callers of is_sp_in_continuation()
>> 
>> ```c++
>> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>>   return entry->entry_sp() > sp;
>> }
>> 
>> 
>> to pass the actual sp. This is correct because the following is true on all platforms:
>> 
>> ```c++
>> a.sp() > E->entry_sp() > b.sp() > c.sp()
>> 
>> 
>> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
>> 
>> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `Unimplemented` definitions of interpreter_frame_last_sp

Thinking about this some more, while sp() may work for all platforms, it seems like frame::id() is what the shared Loom code should really be using.  Then we would have:

`a.id() > E->to_frame().id() > b.id() > c.id()`

The Loom code shouldn't really be assuming that stacks grow in a particular direction.  That is what frame:is_older() is for.  Unfortunately, I found that aarch64 has a problem with this.  Given a frame f, we can't assert on aarch64 that

f.sender().is_older(f.id())

because aarch64 uses unextended_sp() for frame::id().

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From jiefu at openjdk.org  Wed Sep 21 22:58:13 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 21 Sep 2022 22:58:13 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <YId_n7sZfownuHpLtp7iC1FDTx9A4mzZ-eSQC40pilQ=.5c1e223f-3625-4a67-88d2-e099f3604946@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <YId_n7sZfownuHpLtp7iC1FDTx9A4mzZ-eSQC40pilQ=.5c1e223f-3625-4a67-88d2-e099f3604946@github.com>
Message-ID: <wmyf5HGgZZnnk53ZdzqiZQi5xACHbkQYtLyjLzNhbWw=.8201e137-ea19-4d60-835a-209ed47bac3b@github.com>

On Wed, 21 Sep 2022 15:34:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Withdraw my approval per Alan's comment.

Okay.
Thanks @iklam and @AlanBateman .

-------------

PR: https://git.openjdk.org/jdk/pull/10266

From coleenp at openjdk.org  Wed Sep 21 23:04:27 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Sep 2022 23:04:27 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v2]
In-Reply-To: <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
 <IUsuYNJojB21ojHy4s6y-To1YuJU5-HqaaWpVRRQ6vs=.587d2c8d-ecc5-4e74-80b8-b4390740c1dd@github.com>
Message-ID: <KFTkFl60_VpWdLU_YmgjZR18DNP-Z1ezC2K0KvdDZbE=.6f89701a-aa0e-4c86-84c7-c97b3f3cf416@github.com>

On Thu, 15 Sep 2022 21:43:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this fix which involves:
>> 
>> - acquire the `Module_lock` before calling `modules_do`;
>> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
>> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
>> 
>> Passed tiers 1 - 3 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of the _total_count field

thanks!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10291

From ccheung at openjdk.org  Thu Sep 22 03:37:34 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 22 Sep 2022 03:37:34 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v3]
In-Reply-To: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
Message-ID: <3clXR3qDOALKkxIDXWDXAE1XDo41Fzs9oTKjveC3rl0=.10269e12-230f-418c-b0fd-8163ef9bb123@github.com>

> Please review this fix which involves:
> 
> - acquire the `Module_lock` before calling `modules_do`;
> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
> 
> Passed tiers 1 - 3 testing.

Calvin Cheung 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:

 - add assert in modules_do functions
 - Merge branch 'master' into 8292202-modules_do
 - get rid of the _total_count field
 - 8292202: modules_do is called without Module_lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10291/files
  - new: https://git.openjdk.org/jdk/pull/10291/files/9f4e67f9..a3ebd5b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10291&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10291&range=01-02

  Stats: 99962 lines in 1838 files changed: 46911 ins; 41369 del; 11682 mod
  Patch: https://git.openjdk.org/jdk/pull/10291.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10291/head:pull/10291

PR: https://git.openjdk.org/jdk/pull/10291

From ccheung at openjdk.org  Thu Sep 22 03:39:05 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 22 Sep 2022 03:39:05 GMT
Subject: RFR: 8292202: modules_do is called without Module_lock [v3]
In-Reply-To: <VDQ52ZWKUtzcQ7t9ZethsBTNG7c6QUUwRFIqSrvHAxM=.ca750f18-a4c7-4570-9a6d-5bf85bca0461@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
 <VDQ52ZWKUtzcQ7t9ZethsBTNG7c6QUUwRFIqSrvHAxM=.ca750f18-a4c7-4570-9a6d-5bf85bca0461@github.com>
Message-ID: <Po2vCPs0Tx4CzT0MOszsTtUYzPefVMF5I9mNfWw7TQo=.45433395-0c3f-4456-861d-10899cf86a8a@github.com>

On Thu, 15 Sep 2022 18:37:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung 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:
>> 
>>  - add assert in modules_do functions
>>  - Merge branch 'master' into 8292202-modules_do
>>  - get rid of the _total_count field
>>  - 8292202: modules_do is called without Module_lock
>
> Looks good. A minor suggestion to simplify the code.

Thanks @iklam and @coleenp.

-------------

PR: https://git.openjdk.org/jdk/pull/10291

From ccheung at openjdk.org  Thu Sep 22 03:40:34 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 22 Sep 2022 03:40:34 GMT
Subject: Integrated: 8292202: modules_do is called without Module_lock
In-Reply-To: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
References: <bWZZ-mD3sM8GKEUpvL_tWPbM4U8-o58WOsWdZ05nXvg=.80735ef5-dce7-4549-9a89-1813ebbfcf1d@github.com>
Message-ID: <8QDpqCKyq_9b-eu_IjqH2inZ91XOLtXYL5SDKZcGZJo=.08772c40-7d5f-4feb-b417-12befea1c2a9@github.com>

On Thu, 15 Sep 2022 18:01:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this fix which involves:
> 
> - acquire the `Module_lock` before calling `modules_do`;
> - move the call to `ClassLoader::setup_module_search_path `out of `do_module`;
> - save the module paths in a `GrowableArray` in `do_module` for calling `ClassLoader::setup_module_search_path`.
> 
> Passed tiers 1 - 3 testing.

This pull request has now been integrated.

Changeset: 47f233ac
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47f233acec2aec449f001ea3a578cead7f1fc0d9
Stats:     21 lines in 2 files changed: 16 ins; 0 del; 5 mod

8292202: modules_do is called without Module_lock

Reviewed-by: iklam, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/10291

From jiefu at openjdk.org  Thu Sep 22 06:05:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 22 Sep 2022 06:05:25 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
Message-ID: <uqpQiF-Y4Bm0DiIDsmnnT5WxZ1_EepIGrK859NVgDOw=.4ab9af00-1356-4244-9220-1be2a738d34e@github.com>

On Wed, 14 Sep 2022 10:47:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
>> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
>> So it seems better to test the existance of `parent` before creation.
>> 
>> Testing:
>> - tier1~3 on Linux/x64 in progress, seems fine until now
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72
>
> I could reproduce the issue with `Files.createDirectories` on a macos with a trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L808. To me this appears to be something that either needs to be clarified in the the `Files.createDirectories` API or addressed/fixed there. I have asked for inputs on this from others who have more knowledge of this area.

Close this one since it would be fixed by @jaikiran in a separate pr.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10266

From jiefu at openjdk.org  Thu Sep 22 06:05:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 22 Sep 2022 06:05:25 GMT
Subject: Withdrawn: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <50hVfMNYSl_O0Hi_gHVcMRnA3n2hBKGZNRZUz0QGsfc=.cb306b35-c343-4d63-ba61-bc7aabf6b94a@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10266

From rehn at openjdk.org  Thu Sep 22 06:13:21 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 22 Sep 2022 06:13:21 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
Message-ID: <vkwmx3eyXlWo55RjJjMZFRP9msoMZK-Ryw1AsWUxIuo=.27b93d97-8565-43a8-88fc-cb1ece45f741@github.com>

On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
>> 
>> JDK-8290196 12.8: Clarify the definition of program exit
>> https://bugs.openjdk.org/browse/JDK-8290196
>> 
>> JDK-8290388 5.7: Clarify the definition of JVM termination
>> https://bugs.openjdk.org/browse/JDK-8290388
>> 
>> JDK-8290036 Define and specify Runtime shutdown sequence
>> https://bugs.openjdk.org/browse/JDK-8290036
>> 
>> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
>> 
>> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
>> 
>> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
>> 
>> Issue 2 covers the code change, and regression test, in this PR.
>> 
>> In addition the specification changes can be seen here:
>> 
>> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
>> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
>> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
>> 
>> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
>> 
>> Thank you.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JniVersion test

Looks good, thank you!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10352

From shade at openjdk.org  Thu Sep 22 07:14:20 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 07:14:20 GMT
Subject: RFR: 8292847: Zero: Allow ergonomics to select the GC
In-Reply-To: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
References: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
Message-ID: <Ogd4ohicQrVqvPyYF4jZQLAgeHt2iASqKyuVriLLQ5g=.7acce448-83c8-435b-a2de-4700525c76e0@github.com>

On Wed, 24 Aug 2022 06:01:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero is currently defaulting to Serial GC on all machines, due to the fact that `NeverActAsServerClassMachine` is `true`. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`. `NeverActAsServerClassMachine` mostly affects compiler ergonomics, which Zero does not need, but it also affects the selection of default GC.
> 
> After [JDK-8256497](https://bugs.openjdk.org/browse/JDK-8256497), we can let Zero default to G1. After [JDK-8292329](https://bugs.openjdk.org/browse/JDK-8292329), it would help Zero to use the CDS shared heap.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images`
>  - [x]  Linux x86_64 Zero fastdebug, `tier1` tests (many known failures)

Anyone? :)

-------------

PR: https://git.openjdk.org/jdk/pull/9994

From duke at openjdk.org  Thu Sep 22 07:28:00 2022
From: duke at openjdk.org (Fredrik Bredberg)
Date: Thu, 22 Sep 2022 07:28:00 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
Message-ID: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>

The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().

Tested tier1, tier2 and  tier3 without any new problems.

-------------

Commit messages:
 - Removed unneeded local pc variable in handle_safefetch().

Changes: https://git.openjdk.org/jdk/pull/10373/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10373&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294053
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10373.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10373/head:pull/10373

PR: https://git.openjdk.org/jdk/pull/10373

From rehn at openjdk.org  Thu Sep 22 08:05:23 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 22 Sep 2022 08:05:23 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <p9QQlhhUTxTnS0VUC1eqzIDn7yHo_rTjlB_lSM_93Ck=.6ae863e0-f53a-4aa2-80a1-96aa0abd70ad@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

Looks good, thanks!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10373

From dholmes at openjdk.org  Thu Sep 22 08:25:19 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 08:25:19 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <Muaxg7awh9cOP80HJa-V0F51l2VFe-OtiTUttJO0UPE=.ecec8711-9079-40f0-958d-4f116f289b2a@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> and is initialized to the same value as is passed into the handle_safefetch() function by its callers.

Took me a bit to check that due to some confusing logic around SIGILL and SIGFPE handling.
But I'm not clear about what will happen on Zero - it will always pass a pc of NULL where currently we will get it from `ucontext_get_pc(uc)`.

Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From rrich at openjdk.org  Thu Sep 22 09:26:18 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 22 Sep 2022 09:26:18 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <sUqIK2Pee3D9tq08fI2F0d1g8ns90lqXyH1ZvNHEv5M=.b929f07c-c942-4606-85f1-6ee767e91e00@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
 <sUqIK2Pee3D9tq08fI2F0d1g8ns90lqXyH1ZvNHEv5M=.b929f07c-c942-4606-85f1-6ee767e91e00@github.com>
Message-ID: <dxbKL7EeF8N5JI9ksIkq1w6xzTL836Aa1ZAFbTfiMjE=.fd6ff4af-5c54-4beb-b42f-5fbe0e35af4d@github.com>

On Wed, 21 Sep 2022 22:35:10 GMT, Dean Long <dlong at openjdk.org> wrote:

> Thinking about this some more, while sp() may work for all platforms, it seems
> like frame::id() is what the shared Loom code should really be using. Then we
> would have:
>
> `a.id() > E->to_frame().id() > b.id() > c.id()`
> 
> The Loom code shouldn't really be assuming that stacks grow in a particular
> direction. That is what frame:is_older() is for.

With that we would have s.th. like

```C++
bool Continuation::is_frame_in_continuation(const ContinuationEntry* entry, const frame& f) {
  return entry->to_frame().is_older(f.id());
}


and replace all uses of is_sp_in_continuation() with it. Not sure if performance
could be a problem then.

```C++
!f.is_older(entry->frame_id());


with a platform dependent definition of frame_id() could be faster then.

> Unfortunately, I found that aarch64 has a problem with this. Given a frame f,
> we can't assert on aarch64 that
> 
> f.sender().is_older(f.id())
> 
> because aarch64 uses unextended_sp() for frame::id().

Yes indeed there seems to be an issue with is_older() on aarch64 because of the
trimming of interpreted frames.

Actually I assumed hotspot does not abstract over stack growth direction because
it did not back in the days when we've ported it to pa-risc where stacks grow
towards higher addresses (yes that's long ago :))

So there might be is_older() now but looking for instance at [class StackOverflow](https://github.com/openjdk/jdk/blob/d5bee4a0dffebcf3037b83fa3f7bc635dd6b1303/src/hotspot/share/runtime/stackOverflow.hpp#L131-L143)
it is clear from the diagrams and the code that stack growth towards lower
addresses is assumed. I'm sure there's still much more shared code in hotspot
with that assumption.

Another example from Loom is the shared code related to JavaThread::_cont_fastpath
where growth towards lower addresses is assumed too.

We could duplicate is_sp_in_continuation() on the platforms or add a static
assertion on a new global definition of the stack growth direction if you
like. Not sure if it is worth it though. I'd tend towards keeping
is_sp_in_continuation() as it is and maybe create an JBS item for stack growth
issues in Loom.

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From shade at openjdk.org  Thu Sep 22 09:29:18 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 09:29:18 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <Muaxg7awh9cOP80HJa-V0F51l2VFe-OtiTUttJO0UPE=.ecec8711-9079-40f0-958d-4f116f289b2a@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
 <Muaxg7awh9cOP80HJa-V0F51l2VFe-OtiTUttJO0UPE=.ecec8711-9079-40f0-958d-4f116f289b2a@github.com>
Message-ID: <1fj3m_KBOuF3OOi0z6L0Y7HRi1buiwXpRLHWCF-fuO0=.ef8617f9-1b48-44e3-ba52-c57c33ba4099@github.com>

On Thu, 22 Sep 2022 08:21:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > and is initialized to the same value as is passed into the handle_safefetch() function by its callers.
> 
> Took me a bit to check that due to some confusing logic around SIGILL and SIGFPE handling. But I'm not clear about what will happen on Zero - it will always pass a pc of NULL where currently we will get it from `ucontext_get_pc(uc)`.

On Zero, `os::Posix::ucontext_get_pc(uc)` would fail with `ShouldNotReachHere()`, so this patch does not make it worse. `JVM_HANDLE_XXX_SIGNAL` makes a special provision for Zero by always taking `pc = NULL` route.  Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From shade at openjdk.org  Thu Sep 22 09:53:00 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 09:53:00 GMT
Subject: RFR: 8294197: Zero: JVM_handle_linux_signal should not assume deopt
 NOPs
Message-ID: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>

This is a simple regression from Loom added code. In `JVM_handle_linux_signal` there is a new block that handles deopt NOPs. Zero does not have them, and so it currently encounters `ShouldNotReachHere()` when entering the block and doing either `os::Posix::ucontext_get_pc(uc)` or `NativeDeoptInstruction::is_deopt_at(pc)`.

This block should not be entered with Zero at all. 

Additional testing:
 - [x] Artificially crashing Linux x86_64 Zero fastdebug now produces a sensible hs_err

-------------

Commit messages:
 - Argh.
 - Add end clause comment
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10389/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10389&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294197
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10389/head:pull/10389

PR: https://git.openjdk.org/jdk/pull/10389

From duke at openjdk.org  Thu Sep 22 10:02:22 2022
From: duke at openjdk.org (Fredrik Bredberg)
Date: Thu, 22 Sep 2022 10:02:22 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <Rd2Sn1AOncfv5AB0he-nvCMtNHQnoI7mA-6aQ120NXw=.ae23d302-aec4-4477-bc35-7d0497f2df55@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

I assumed that if it was possible to get hold of the pc on Zero, that would have been done by calling os::Posix::ucontext_get_pc(uc) in JVM_HANDLE_XXX_SIGNAL prior to calling handle_safefetch().
I hope this patch haven't done things worse. My intention was just to remove a "local variable shadows a parameter" issue, which I don't think should be in any code base.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From simonis at openjdk.org  Thu Sep 22 10:42:17 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Sep 2022 10:42:17 GMT
Subject: RFR: 8294037: Using alias template to unify hashtables in
 AsyncLogWriter
In-Reply-To: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
References: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
Message-ID: <6sP90Cd3uIxr_OpovCSmYrq-4vgbzUw2I1VwTexq3G4=.dd5f9f53-b09a-4ec3-bee1-98fcdf1ca068@github.com>

On Mon, 19 Sep 2022 21:02:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This change is only for clear code. No functional change is intended.
> 
> Currently, there are two hashtables. One is this on c-heap.
> 
>   using AsyncLogMap = ResourceHashtable<LogFileStreamOutput*,
>                           uint32_t,
>                           17, /*table_size*/
>                           ResourceObj::C_HEAP,
>                           mtLogging>;
> 
> and the other one is its mirror on ResourceArena. It's not accident. The 2nd one is the snapshot of prior one. 
> We use this approach to release lock early. Flushing snapshot doesn't require lock protection and therefore 
> won't block logsites.
> 
> 
>   ResourceMark rm;
>   // Similar to AsyncLogMap but on resource_area
>   ResourceHashtable<LogFileStreamOutput*, uint32_t,
>                           17/*table_size*/, ResourceObj::RESOURCE_AREA,
>                           mtLogging> snapshot;
> 
> C++11 has a new feature called [alias template](https://en.cppreference.com/w/cpp/language/type_alias). We can
> use this feature to unify two types.

Thanks for teaching us new C++ features :)

This change looks good and like a nice cleanup. Also verified that at least VSC/ccls can handle it nicely.

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10350

From stuefe at openjdk.org  Thu Sep 22 12:42:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Sep 2022 12:42:18 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <SMVxptSu5ori4j4zQMit4RG-3bs7r0K54cGvyzDA6cQ=.f2f17185-aeae-42e5-b96c-bfd1bd3d62bd@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

Kim marked this and other issues in https://bugs.openjdk.org/browse/JDK-8292166. If this RFE gets pushed, https://bugs.openjdk.org/browse/JDK-8292166 should get adapted.

> On Zero, `os::Posix::ucontext_get_pc(uc)` would fail with `ShouldNotReachHere()`, so this patch does not make it worse. 

Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right? 

> `JVM_HANDLE_XXX_SIGNAL` makes a special provision for Zero by always taking `pc = NULL` route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.

Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From coleenp at openjdk.org  Thu Sep 22 12:47:18 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Sep 2022 12:47:18 GMT
Subject: RFR: 8294197: Zero: JVM_handle_linux_signal should not assume
 deopt NOPs
In-Reply-To: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>
References: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>
Message-ID: <IMcLQD3RUdgWNcaY2Wk29CqdWKmZApZxKe0S9RP8PQA=.20a249d7-6aca-481b-8cc9-766c2b0977b9@github.com>

On Thu, 22 Sep 2022 09:45:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is a simple regression from Loom added code. In `JVM_handle_linux_signal` there is a new block that handles deopt NOPs. Zero does not have them, and so it currently encounters `ShouldNotReachHere()` when entering the block and doing either `os::Posix::ucontext_get_pc(uc)` or `NativeDeoptInstruction::is_deopt_at(pc)`.
> 
> This block should not be entered with Zero at all. 
> 
> Additional testing:
>  - [x] Artificially crashing Linux x86_64 Zero fastdebug now produces a sensible hs_err

Looks good plus trivial.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10389

From dholmes at openjdk.org  Thu Sep 22 12:48:22 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 12:48:22 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <Rd2Sn1AOncfv5AB0he-nvCMtNHQnoI7mA-6aQ120NXw=.ae23d302-aec4-4477-bc35-7d0497f2df55@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
 <Rd2Sn1AOncfv5AB0he-nvCMtNHQnoI7mA-6aQ120NXw=.ae23d302-aec4-4477-bc35-7d0497f2df55@github.com>
Message-ID: <2xL4nsl_HlKiQ46Xwj_HE8UTYIOiTTyBYjqvqocrykY=.020d8749-fdd7-4a03-b588-9619bcc5795a@github.com>

On Thu, 22 Sep 2022 09:58:27 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> My intention was just to remove a "local variable shadows a parameter" issue

Yes but based on JDK-8292166 the problem may not be the local, but the passing of the unused argument. It may be better to just drop this PR and let JDK-8292166 perform a broader cleanup of this code.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From shade at openjdk.org  Thu Sep 22 14:49:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 14:49:24 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <SMVxptSu5ori4j4zQMit4RG-3bs7r0K54cGvyzDA6cQ=.f2f17185-aeae-42e5-b96c-bfd1bd3d62bd@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
 <SMVxptSu5ori4j4zQMit4RG-3bs7r0K54cGvyzDA6cQ=.f2f17185-aeae-42e5-b96c-bfd1bd3d62bd@github.com>
Message-ID: <hn1wybwk82ay6nOtgaRlLGSjEdXnfG3AwDxnOVNitS0=.b0068b04-b397-4461-ae45-26023373ab87@github.com>

On Thu, 22 Sep 2022 12:38:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 
> > On Zero, `os::Posix::ucontext_get_pc(uc)` would fail with `ShouldNotReachHere()`, so this patch does not make it worse.
> 
> Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right?

Quite right, I actually started doing that today in https://bugs.openjdk.org/browse/JDK-8294211. My point is that removing the `os::Posix::ucontext_get_pc(uc);` in this PR does nothing bad for Zero AFAICS, because current (shadowd) `pc` is `nullptr`, and calling `ucontext_get_pc(uc)` would just meet `ShouldNotReachHere()`. After JDK-8294211 is done, the `pc` would be from `ucontext_get_pc(uc)` anyway.

> > `JVM_HANDLE_XXX_SIGNAL` makes a special provision for Zero by always taking `pc = NULL` route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.
> 
> Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.

Yes, so I discovered when working on JDK-8294211. My patch seems to work with safefetch, at least I can gdb my way trough safefetch_sigjmp code at Linux x86_65 Zero.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From shade at openjdk.org  Thu Sep 22 14:52:37 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 14:52:37 GMT
Subject: RFR: 8294197: Zero: JVM_handle_linux_signal should not assume
 deopt NOPs
In-Reply-To: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>
References: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>
Message-ID: <nCJtOubdaWTM2sqe4NvYaq6uryTN9bmENoX74q4nkeA=.fd8fb6fb-4ecb-4a13-828c-0ea85110ed11@github.com>

On Thu, 22 Sep 2022 09:45:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is a simple regression from Loom added code. In `JVM_handle_linux_signal` there is a new block that handles deopt NOPs. Zero does not have them, and so it currently encounters `ShouldNotReachHere()` when entering the block and doing either `os::Posix::ucontext_get_pc(uc)` or `NativeDeoptInstruction::is_deopt_at(pc)`.
> 
> This block should not be entered with Zero at all. 
> 
> Additional testing:
>  - [x] Artificially crashing Linux x86_64 Zero fastdebug now produces a sensible hs_err

Thanks! I'll integrate, as related Zero work relies on this.

-------------

PR: https://git.openjdk.org/jdk/pull/10389

From shade at openjdk.org  Thu Sep 22 14:54:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 14:54:08 GMT
Subject: Integrated: 8294197: Zero: JVM_handle_linux_signal should not assume
 deopt NOPs
In-Reply-To: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>
References: <FyRfQUBFvfsYP2FV9sqt1Y3HVIg6CmVOyeWhjGV_nGY=.a237532f-ba1c-4327-a34a-dac7ba4237cb@github.com>
Message-ID: <u1PYkAbeoAC6vID3whOauIq3akCRpdLejcbmO_0ox1k=.75f7cd76-93a3-4d1e-83df-f61ab31be7a9@github.com>

On Thu, 22 Sep 2022 09:45:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is a simple regression from Loom added code. In `JVM_handle_linux_signal` there is a new block that handles deopt NOPs. Zero does not have them, and so it currently encounters `ShouldNotReachHere()` when entering the block and doing either `os::Posix::ucontext_get_pc(uc)` or `NativeDeoptInstruction::is_deopt_at(pc)`.
> 
> This block should not be entered with Zero at all. 
> 
> Additional testing:
>  - [x] Artificially crashing Linux x86_64 Zero fastdebug now produces a sensible hs_err

This pull request has now been integrated.

Changeset: f751e608
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f751e6087d24012ecc0e6bc74d5572794a7c85d6
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8294197: Zero: JVM_handle_linux_signal should not assume deopt NOPs

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/10389

From stuefe at openjdk.org  Thu Sep 22 15:07:19 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Sep 2022 15:07:19 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <hn1wybwk82ay6nOtgaRlLGSjEdXnfG3AwDxnOVNitS0=.b0068b04-b397-4461-ae45-26023373ab87@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
 <SMVxptSu5ori4j4zQMit4RG-3bs7r0K54cGvyzDA6cQ=.f2f17185-aeae-42e5-b96c-bfd1bd3d62bd@github.com>
 <hn1wybwk82ay6nOtgaRlLGSjEdXnfG3AwDxnOVNitS0=.b0068b04-b397-4461-ae45-26023373ab87@github.com>
Message-ID: <meJgQK0MApfuCUSi98e4NwbAO4MkIf4jw8MVCA6v35Y=.0a908ed8-2f28-4d8d-86b3-21502ea5bd65@github.com>

On Thu, 22 Sep 2022 14:45:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > On Zero, `os::Posix::ucontext_get_pc(uc)` would fail with `ShouldNotReachHere()`, so this patch does not make it worse.
> > 
> > 
> > Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right?
> 
> Quite right, I actually started doing that today in https://bugs.openjdk.org/browse/JDK-8294211. My point is that removing the `os::Posix::ucontext_get_pc(uc);` in this PR does nothing bad for Zero AFAICS, because current (shadowd) `pc` is `nullptr`, and calling `ucontext_get_pc(uc)` would just meet `ShouldNotReachHere()`. After JDK-8294211 is done, the `pc` would be from `ucontext_get_pc(uc)` anyway.

Makes sense.

> 
> > > `JVM_HANDLE_XXX_SIGNAL` makes a special provision for Zero by always taking `pc = NULL` route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.
> > 
> > 
> > Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.
> 
> Yes, so I discovered when working on JDK-8294211. My patch seems to work with safefetch, at least I can gdb my way trough safefetch_sigjmp code at Linux x86_65 Zero.

We have gtests for SafeFetch (https://github.com/openjdk/jdk/blob/master/test/hotspot/gtest/runtime/test_safefetch.cpp) and jtreg tests for SafeFetch during signal handling (eg. when writing hs-err files) https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java . If those are green, all is well.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From tschatzl at openjdk.org  Thu Sep 22 15:26:38 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 22 Sep 2022 15:26:38 GMT
Subject: RFR: 8292847: Zero: Allow ergonomics to select the GC
In-Reply-To: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
References: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
Message-ID: <jdGq9vXqCqk1maa_j3eugOC1jeAxfrt7r9sg9bj1il8=.1674567a-940d-41c1-9ff3-2606f312847b@github.com>

On Wed, 24 Aug 2022 06:01:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero is currently defaulting to Serial GC on all machines, due to the fact that `NeverActAsServerClassMachine` is `true`. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`. `NeverActAsServerClassMachine` mostly affects compiler ergonomics, which Zero does not need, but it also affects the selection of default GC.
> 
> After [JDK-8256497](https://bugs.openjdk.org/browse/JDK-8256497), we can let Zero default to G1. After [JDK-8292329](https://bugs.openjdk.org/browse/JDK-8292329), it would help Zero to use the CDS shared heap.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images`
>  - [x]  Linux x86_64 Zero fastdebug, `tier1` tests (many known failures)

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9994

From xliu at openjdk.org  Thu Sep 22 16:17:19 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 22 Sep 2022 16:17:19 GMT
Subject: RFR: 8294075: gtest/AsyncLogGtest crashes with SEGV
In-Reply-To: <eSBzTQPP4PvD8N4prJqB6Ts778PD0ZnFTURA4nSkAfk=.21fc33b7-3070-4c5d-92ba-7d31b059cbc4@github.com>
References: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
 <eSBzTQPP4PvD8N4prJqB6Ts778PD0ZnFTURA4nSkAfk=.21fc33b7-3070-4c5d-92ba-7d31b059cbc4@github.com>
Message-ID: <uvAraOf6SiXfV3vJABPL42wlAgG8qhgxkrW5MHab-yY=.dd20434a-ab79-48a2-86a4-c960a121e2ce@github.com>

On Wed, 21 Sep 2022 10:37:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In order to test "drop messages scenario", I replace the serving buffers with shrunk buffers(1k).
>> This is done by RAII class 'AsyncLogWriter::BufferUpdater'. There is a race condition between test and AsyncLog thread. 
>> The race condition exhibits when AsyncLog thread is still processing `buffer_staging` but test thread deletes it in dtor of BufferUpdater. 
>> 
>> This patch issues AsyncLogWriter::flush() before dtor of BufferUpdater. buffers are reverted only when pending messages have all been handled.
>> 
>> I test TEST="jtreg:hotspot/jtreg/gtest/AsyncLogGtest.java" 100 times and never see race condition.
>
> Yes, seems reasonable.

hi, @shipilev 

Thank you for reviewing this patch. Is it possible that you start a test for tier1~6? 
My understanding is the infra hits this issue because it may run some tests in single-core container environment.  The the kernel preemption triggers the race condition more likely.  I simulate this using taskset locally. 

I wish we could verify this patch works before checking in.

-------------

PR: https://git.openjdk.org/jdk/pull/10367

From xliu at openjdk.org  Thu Sep 22 16:20:26 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 22 Sep 2022 16:20:26 GMT
Subject: RFR: 8294037: Using alias template to unify hashtables in
 AsyncLogWriter
In-Reply-To: <TyZHsGrdqoRwqi4jMvjHvPxEvWFzaGv7pxodGkqYgtg=.71fbb0e1-eeaa-4e82-8297-16e24fec8d89@github.com>
References: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
 <TyZHsGrdqoRwqi4jMvjHvPxEvWFzaGv7pxodGkqYgtg=.71fbb0e1-eeaa-4e82-8297-16e24fec8d89@github.com>
Message-ID: <a2ktRIcHcDvd8IQVkA9-fCsG8dFiKadq0y9p0IwB9_Q=.beb37639-8530-4f90-b89d-8d18e6467cb1@github.com>

On Wed, 21 Sep 2022 13:28:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change is only for clear code. No functional change is intended.
>> 
>> Currently, there are two hashtables. One is this on c-heap.
>> 
>>   using AsyncLogMap = ResourceHashtable<LogFileStreamOutput*,
>>                           uint32_t,
>>                           17, /*table_size*/
>>                           ResourceObj::C_HEAP,
>>                           mtLogging>;
>> 
>> and the other one is its mirror on ResourceArena. It's not accident. The 2nd one is the snapshot of prior one. 
>> We use this approach to release lock early. Flushing snapshot doesn't require lock protection and therefore 
>> won't block logsites.
>> 
>> 
>>   ResourceMark rm;
>>   // Similar to AsyncLogMap but on resource_area
>>   ResourceHashtable<LogFileStreamOutput*, uint32_t,
>>                           17/*table_size*/, ResourceObj::RESOURCE_AREA,
>>                           mtLogging> snapshot;
>> 
>> C++11 has a new feature called [alias template](https://en.cppreference.com/w/cpp/language/type_alias). We can
>> use this feature to unify two types.
>
> Marked as reviewed by coleenp (Reviewer).

hi, @coleenp and @simonis , 
thank you for reviewing this patch!

-------------

PR: https://git.openjdk.org/jdk/pull/10350

From shade at openjdk.org  Thu Sep 22 16:26:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 16:26:16 GMT
Subject: RFR: 8294075: gtest/AsyncLogGtest crashes with SEGV
In-Reply-To: <uvAraOf6SiXfV3vJABPL42wlAgG8qhgxkrW5MHab-yY=.dd20434a-ab79-48a2-86a4-c960a121e2ce@github.com>
References: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
 <eSBzTQPP4PvD8N4prJqB6Ts778PD0ZnFTURA4nSkAfk=.21fc33b7-3070-4c5d-92ba-7d31b059cbc4@github.com>
 <uvAraOf6SiXfV3vJABPL42wlAgG8qhgxkrW5MHab-yY=.dd20434a-ab79-48a2-86a4-c960a121e2ce@github.com>
Message-ID: <PQIWvzdtm9OR2tSizML2rQqGShreurMCd4vscN6Ir_E=.5b902ca1-414d-45bc-a865-43ea33ef7f17@github.com>

On Thu, 22 Sep 2022 16:13:52 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Thank you for reviewing this patch. Is it possible that you start a test for tier1~6? My understanding is the infra hits this issue because it may run some tests in single-core container environment. The the kernel preemption triggers the race condition more likely. I simulate this using taskset locally.

I don't have access to Oracle test systems. But I think since you can reproduce it in a stress test, and it fails before, and it passes after the fix, it is enough to claim success here. If there are future sightings, another bug can be submitted.

-------------

PR: https://git.openjdk.org/jdk/pull/10367

From xliu at openjdk.org  Thu Sep 22 16:40:29 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 22 Sep 2022 16:40:29 GMT
Subject: Integrated: 8294037: Using alias template to unify hashtables in
 AsyncLogWriter
In-Reply-To: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
References: <AFpj6jFS3TDmyB5dtVoG2AIf-SEZhde7z0ZSl_ElAds=.d61a39be-7698-4dc2-9f05-01935508a3e5@github.com>
Message-ID: <6UODD3bHfRaByKtpTKzZJVgKXUdsdj0QCZzwx-gzZ1M=.a35c4e22-47fe-4838-a43e-979e816efc32@github.com>

On Mon, 19 Sep 2022 21:02:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This change is only for clear code. No functional change is intended.
> 
> Currently, there are two hashtables. One is this on c-heap.
> 
>   using AsyncLogMap = ResourceHashtable<LogFileStreamOutput*,
>                           uint32_t,
>                           17, /*table_size*/
>                           ResourceObj::C_HEAP,
>                           mtLogging>;
> 
> and the other one is its mirror on ResourceArena. It's not accident. The 2nd one is the snapshot of prior one. 
> We use this approach to release lock early. Flushing snapshot doesn't require lock protection and therefore 
> won't block logsites.
> 
> 
>   ResourceMark rm;
>   // Similar to AsyncLogMap but on resource_area
>   ResourceHashtable<LogFileStreamOutput*, uint32_t,
>                           17/*table_size*/, ResourceObj::RESOURCE_AREA,
>                           mtLogging> snapshot;
> 
> C++11 has a new feature called [alias template](https://en.cppreference.com/w/cpp/language/type_alias). We can
> use this feature to unify two types.

This pull request has now been integrated.

Changeset: 696287d6
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/696287d6e8bf621c225b88f10481966a35c61ffc
Stats:     12 lines in 2 files changed: 3 ins; 5 del; 4 mod

8294037: Using alias template to unify hashtables in AsyncLogWriter

Reviewed-by: coleenp, simonis

-------------

PR: https://git.openjdk.org/jdk/pull/10350

From xliu at openjdk.org  Thu Sep 22 16:41:05 2022
From: xliu at openjdk.org (Xin Liu)
Date: Thu, 22 Sep 2022 16:41:05 GMT
Subject: Integrated: 8294075: gtest/AsyncLogGtest crashes with SEGV
In-Reply-To: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
References: <eH4hI_Te8qdLzdYzbsL_MVen_vdXSaDB1rA0QG22MAs=.5c050d4e-5417-4258-8d1d-71336da3d2a4@github.com>
Message-ID: <81Qei-N9clB84C07F-02Y-k8u26vQvShRoILlViB7AY=.c3ff608c-96ee-4ff4-a4f4-3c29317bbdd4@github.com>

On Wed, 21 Sep 2022 02:34:03 GMT, Xin Liu <xliu at openjdk.org> wrote:

> In order to test "drop messages scenario", I replace the serving buffers with shrunk buffers(1k).
> This is done by RAII class 'AsyncLogWriter::BufferUpdater'. There is a race condition between test and AsyncLog thread. 
> The race condition exhibits when AsyncLog thread is still processing `buffer_staging` but test thread deletes it in dtor of BufferUpdater. 
> 
> This patch issues AsyncLogWriter::flush() before dtor of BufferUpdater. buffers are reverted only when pending messages have all been handled.
> 
> I test TEST="jtreg:hotspot/jtreg/gtest/AsyncLogGtest.java" 100 times and never see race condition.

This pull request has now been integrated.

Changeset: 5285035e
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5285035ed9bb43a40108e4d046e0de317730f193
Stats:     9 lines in 1 file changed: 4 ins; 0 del; 5 mod

8294075: gtest/AsyncLogGtest crashes with SEGV

Reviewed-by: dholmes, shade

-------------

PR: https://git.openjdk.org/jdk/pull/10367

From stuefe at openjdk.org  Thu Sep 22 16:44:47 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Sep 2022 16:44:47 GMT
Subject: RFR: 8292847: Zero: Allow ergonomics to select the GC
In-Reply-To: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
References: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
Message-ID: <WtSKt_m4xAShQCPu8xt1KFAp88Ilrutb0FDyavdmbqQ=.831040e7-a0bf-479d-b618-8fb6984ced30@github.com>

On Wed, 24 Aug 2022 06:01:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero is currently defaulting to Serial GC on all machines, due to the fact that `NeverActAsServerClassMachine` is `true`. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`. `NeverActAsServerClassMachine` mostly affects compiler ergonomics, which Zero does not need, but it also affects the selection of default GC.
> 
> After [JDK-8256497](https://bugs.openjdk.org/browse/JDK-8256497), we can let Zero default to G1. After [JDK-8292329](https://bugs.openjdk.org/browse/JDK-8292329), it would help Zero to use the CDS shared heap.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images`
>  - [x]  Linux x86_64 Zero fastdebug, `tier1` tests (many known failures)

This seems fine.

Just wondered whether one could change the definition in compiler_globals_pd.hpp in the `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI` section to the same effect.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9994

From shade at openjdk.org  Thu Sep 22 18:05:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 18:05:22 GMT
Subject: RFR: 8292847: Zero: Allow ergonomics to select the GC
In-Reply-To: <WtSKt_m4xAShQCPu8xt1KFAp88Ilrutb0FDyavdmbqQ=.831040e7-a0bf-479d-b618-8fb6984ced30@github.com>
References: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
 <WtSKt_m4xAShQCPu8xt1KFAp88Ilrutb0FDyavdmbqQ=.831040e7-a0bf-479d-b618-8fb6984ced30@github.com>
Message-ID: <W8ALSR05fofComiULN4755FldiStHxbGKB7LApzHDmQ=.f854e717-e35e-4b1d-81ca-7cfb9cbc6795@github.com>

On Thu, 22 Sep 2022 16:41:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Just wondered whether one could change the definition in compiler_globals_pd.hpp in the `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI` section to the same effect.

I prefer not to mess with these, because they are part of server/client/etc VM selection ergonomics.

-------------

PR: https://git.openjdk.org/jdk/pull/9994

From dlong at openjdk.org  Thu Sep 22 21:16:17 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 22 Sep 2022 21:16:17 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
Message-ID: <5DGoYOUaKaJgu4Xxh-rGGfJvSCEh-RbbOZ_ftH94WWg=.c6e2be45-0688-4e1c-a138-de6e445b0842@github.com>

On Wed, 21 Sep 2022 07:04:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
>> 
>> This fix changes the callers of is_sp_in_continuation()
>> 
>> ```c++
>> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>>   return entry->entry_sp() > sp;
>> }
>> 
>> 
>> to pass the actual sp. This is correct because the following is true on all platforms:
>> 
>> ```c++
>> a.sp() > E->entry_sp() > b.sp() > c.sp()
>> 
>> 
>> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
>> 
>> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `Unimplemented` definitions of interpreter_frame_last_sp

Yes, there would be quite a bit of fan-out if we decided to go with frame::id().  There are a few places where we could call is_sp_in_continuation() with a frame instead of an id.  Also, as you pointed out, there is still _cont_fastpath that uses an sp.  That field as well as entry->_parent_cont_fastpath should probably be using frame::id().  A new JBS enhancement for that makes sense.

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From dholmes at openjdk.org  Thu Sep 22 21:55:17 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 21:55:17 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <vkwmx3eyXlWo55RjJjMZFRP9msoMZK-Ryw1AsWUxIuo=.27b93d97-8565-43a8-88fc-cb1ece45f741@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
 <vkwmx3eyXlWo55RjJjMZFRP9msoMZK-Ryw1AsWUxIuo=.27b93d97-8565-43a8-88fc-cb1ece45f741@github.com>
Message-ID: <XvVAjAMOZwY6q4Q508S7Y0fDU3-zJ-AsE2Xcsipwf-I=.7e8b5721-48aa-430c-a000-51032a34fb08@github.com>

On Thu, 22 Sep 2022 06:09:46 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix JniVersion test
>
> Looks good, thank you!

Thanks @robehn !

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From rehn at openjdk.org  Fri Sep 23 07:15:15 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 23 Sep 2022 07:15:15 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <hn1wybwk82ay6nOtgaRlLGSjEdXnfG3AwDxnOVNitS0=.b0068b04-b397-4461-ae45-26023373ab87@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
 <SMVxptSu5ori4j4zQMit4RG-3bs7r0K54cGvyzDA6cQ=.f2f17185-aeae-42e5-b96c-bfd1bd3d62bd@github.com>
 <hn1wybwk82ay6nOtgaRlLGSjEdXnfG3AwDxnOVNitS0=.b0068b04-b397-4461-ae45-26023373ab87@github.com>
Message-ID: <N5_RaCWe9csDyIeuVrf5I7MAbGL6duzRhGCPpchMoGE=.ed78ce63-04dc-4d6c-afe0-d376b2a9dba9@github.com>

On Thu, 22 Sep 2022 14:45:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kim marked this and other issues in https://bugs.openjdk.org/browse/JDK-8292166. If this RFE gets pushed, https://bugs.openjdk.org/browse/JDK-8292166 should get adapted.
>> 
>>> On Zero, `os::Posix::ucontext_get_pc(uc)` would fail with `ShouldNotReachHere()`, so this patch does not make it worse. 
>> 
>> Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right? 
>> 
>>> `JVM_HANDLE_XXX_SIGNAL` makes a special provision for Zero by always taking `pc = NULL` route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.
>> 
>> Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.
>
>> 
>> > On Zero, `os::Posix::ucontext_get_pc(uc)` would fail with `ShouldNotReachHere()`, so this patch does not make it worse.
>> 
>> Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right?
> 
> Quite right, I actually started doing that today in https://bugs.openjdk.org/browse/JDK-8294211. My point is that removing the `os::Posix::ucontext_get_pc(uc);` in this PR does nothing bad for Zero AFAICS, because current (shadowd) `pc` is `nullptr`, and calling `ucontext_get_pc(uc)` would just meet `ShouldNotReachHere()`. After JDK-8294211 is done, the `pc` would be from `ucontext_get_pc(uc)` anyway.
> 
>> > `JVM_HANDLE_XXX_SIGNAL` makes a special provision for Zero by always taking `pc = NULL` route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.
>> 
>> Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.
> 
> Yes, so I discovered when working on JDK-8294211. My patch seems to work with safefetch, at least I can gdb my way trough safefetch_sigjmp code at Linux x86_65 Zero.

@shipilev and @tstuefe, if you are fine with this going in now can you please review it, otherwise advice @fbredber to close, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From stuefe at openjdk.org  Fri Sep 23 07:50:16 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 Sep 2022 07:50:16 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <biBgY24ieKyn51I1AGsEORXwe8-d0sLPkHB4oz08few=.44b6ee2f-ab1a-48c6-af26-9e121ebe1241@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

I think its fine as it is. One thing less to cleanup with JDK-8292166.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10373

From shade at openjdk.org  Fri Sep 23 08:52:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 08:52:16 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <0WtvINLRpFgWNwujWmhZIy7UGYX94MG37xf3zXnCexU=.7e414ad6-c81f-46be-b014-dfc9ca9c5330@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

I don't mind this going in.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10373

From jsjolen at openjdk.org  Fri Sep 23 10:38:21 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 23 Sep 2022 10:38:21 GMT
Subject: RFR: 8293873: Centralize the initialization of UL [v2]
In-Reply-To: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
Message-ID: <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>

> Hi,
> 
> May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.
> 
> Tier 2 and 3 tests are currently running, all green so far.
> 
> Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10307/files
  - new: https://git.openjdk.org/jdk/pull/10307/files/d5ffa061..b1ee0f3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10307&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10307&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10307.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10307/head:pull/10307

PR: https://git.openjdk.org/jdk/pull/10307

From duke at openjdk.org  Fri Sep 23 12:29:30 2022
From: duke at openjdk.org (Fredrik Bredberg)
Date: Fri, 23 Sep 2022 12:29:30 GMT
Subject: RFR: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <JPzLvtS6tdEoI4cTJT3EEZ5YF9Xamz7XlETWANDfzJg=.8534cd04-fcba-4066-b062-8c3cf22b58b3@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

Thank you for the review comments and "providing the bigger picture".

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From duke at openjdk.org  Fri Sep 23 12:37:51 2022
From: duke at openjdk.org (Fredrik Bredberg)
Date: Fri, 23 Sep 2022 12:37:51 GMT
Subject: Integrated: 8294053: Unneeded local variable in handle_safefetch()
In-Reply-To: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
References: <x_Rwq6T7Q9BBSHQve4t7lVUh-cvB-u9HwXzkY0Rrnaw=.0fa25093-399b-4cb0-97be-c92405021bcb@github.com>
Message-ID: <Gwbecw62l9pRFEYsFz-pQYACNdN2uxdC8ivXNVDPYR8=.7ed14569-0cf8-4037-be3a-72252eb779a9@github.com>

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().
> 
> Tested tier1, tier2 and  tier3 without any new problems.

This pull request has now been integrated.

Changeset: acd75e0f
Author:    Fredrik Bredberg <fredrik.bredberg at oracle.com>
Committer: Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acd75e0f1cddf8307bf0ef4f95a6f11051c30bc2
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8294053: Unneeded local variable in handle_safefetch()

Reviewed-by: rehn, stuefe, shade

-------------

PR: https://git.openjdk.org/jdk/pull/10373

From coleenp at openjdk.org  Fri Sep 23 12:43:15 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Sep 2022 12:43:15 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
Message-ID: <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com>

On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
>> 
>> JDK-8290196 12.8: Clarify the definition of program exit
>> https://bugs.openjdk.org/browse/JDK-8290196
>> 
>> JDK-8290388 5.7: Clarify the definition of JVM termination
>> https://bugs.openjdk.org/browse/JDK-8290388
>> 
>> JDK-8290036 Define and specify Runtime shutdown sequence
>> https://bugs.openjdk.org/browse/JDK-8290036
>> 
>> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
>> 
>> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
>> 
>> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
>> 
>> Issue 2 covers the code change, and regression test, in this PR.
>> 
>> In addition the specification changes can be seen here:
>> 
>> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
>> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
>> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
>> 
>> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
>> 
>> Thank you.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JniVersion test

This seems good.  I looked at the specification changes and they looked okay also.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10352

From stuefe at openjdk.org  Fri Sep 23 14:05:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 Sep 2022 14:05:18 GMT
Subject: RFR: 8293873: Centralize the initialization of UL [v2]
In-Reply-To: <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
Message-ID: <JyeGIy8X40O_2LHbOGnjzKFy_e2zgYhaMhcRrJDd_xc=.f44d9f0a-e1e4-42ea-b8f8-948326514b84@github.com>

On Fri, 23 Sep 2022 10:38:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.
>> 
>> Tier 2 and 3 tests are currently running, all green so far.
>> 
>> Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

Not a full review, since I'm about to go into vacation mode. But I like this, this is cleaner than before.

Not your patch, but the gtests made me think. Some of them are TEST, not TEST_VM, and I wonder if that's deliberate. TEST tests don't initialize the VM. Whether or not the VM infrastructure exists depends on whether a TEST_VM test happened to run before, so the tests depend on order of execution (which is annoying :-( )

If you run the LogTestSet tests isolated (--gtest_filter=LogTagSet_xxx), do they succeed?

Another thing to ponder is that the LogConfiguration gtests modify global state, AFAICS. But gtests should not have side effects. And they should be executable repeatedly (--gtest_repeat=xx). Therefore, these tests maybe should be TEST_OTHER_VM.

Cheers, Thomas

src/hotspot/share/logging/logFileStreamOutput.hpp line 77:

> 75:   LogStdoutOutput() : LogFileStreamOutput(stdout) {
> 76:     set_config_string("all=warning");
> 77:   }

Since you are here :-)

Wonder whether `_config_string` and `_config_string_buffer_size` could be replaced by an inline `stringStream,` and then we could save the awkward string shuffling in `set_config_string()` and `add_to_config_string()`.

-------------

PR: https://git.openjdk.org/jdk/pull/10307

From rrich at openjdk.org  Fri Sep 23 14:12:21 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 23 Sep 2022 14:12:21 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
Message-ID: <MecE-wiAQVXTgUhJuvJAhMci7Cyar6joduPQziu7_aM=.71713db4-daf7-4892-a11c-1d7a3b52086b@github.com>

On Wed, 21 Sep 2022 07:04:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
>> 
>> This fix changes the callers of is_sp_in_continuation()
>> 
>> ```c++
>> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>>   return entry->entry_sp() > sp;
>> }
>> 
>> 
>> to pass the actual sp. This is correct because the following is true on all platforms:
>> 
>> ```c++
>> a.sp() > E->entry_sp() > b.sp() > c.sp()
>> 
>> 
>> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
>> 
>> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `Unimplemented` definitions of interpreter_frame_last_sp

Ok. I have created https://bugs.openjdk.org/browse/JDK-8294284.

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From dlong at openjdk.org  Fri Sep 23 18:59:25 2022
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Sep 2022 18:59:25 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
Message-ID: <Oy16EMOG-fvGpDQJKa2a-fyMZvBf4eLB_qKOPhydW_c=.ba8d8d3f-ae98-4f0a-b987-50ddedb3c32c@github.com>

On Wed, 21 Sep 2022 07:04:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
>> 
>> This fix changes the callers of is_sp_in_continuation()
>> 
>> ```c++
>> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>>   return entry->entry_sp() > sp;
>> }
>> 
>> 
>> to pass the actual sp. This is correct because the following is true on all platforms:
>> 
>> ```c++
>> a.sp() > E->entry_sp() > b.sp() > c.sp()
>> 
>> 
>> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
>> 
>> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `Unimplemented` definitions of interpreter_frame_last_sp

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From dlong at openjdk.org  Fri Sep 23 18:59:27 2022
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Sep 2022 18:59:27 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <MecE-wiAQVXTgUhJuvJAhMci7Cyar6joduPQziu7_aM=.71713db4-daf7-4892-a11c-1d7a3b52086b@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
 <MecE-wiAQVXTgUhJuvJAhMci7Cyar6joduPQziu7_aM=.71713db4-daf7-4892-a11c-1d7a3b52086b@github.com>
Message-ID: <ejbB_QnEPAVWuUZkSrmSRtA2IXGEA5WkWVkr9dD0HTg=.951cbfaa-377e-4a06-a1cd-ee9cff618955@github.com>

On Fri, 23 Sep 2022 14:10:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Ok. I have created https://bugs.openjdk.org/browse/JDK-8294284.

Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From dlong at openjdk.org  Fri Sep 23 19:03:29 2022
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Sep 2022 19:03:29 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
Message-ID: <cTFe5ly-5M7CylqOjvZKIPlleiyyNBzafMFKNv7l_dM=.f7578b58-7536-4efc-857b-64e56a40af1b@github.com>

On Wed, 21 Sep 2022 07:04:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
>> 
>> This fix changes the callers of is_sp_in_continuation()
>> 
>> ```c++
>> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>>   return entry->entry_sp() > sp;
>> }
>> 
>> 
>> to pass the actual sp. This is correct because the following is true on all platforms:
>> 
>> ```c++
>> a.sp() > E->entry_sp() > b.sp() > c.sp()
>> 
>> 
>> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
>> 
>> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `Unimplemented` definitions of interpreter_frame_last_sp

I think it would be good to also have this looked at by someone from hotspot-runtime.  @coleenp, could you take a look?

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From dholmes at openjdk.org  Mon Sep 26 07:19:27 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Sep 2022 07:19:27 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
 <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com>
Message-ID: <dGZQeQczpT7DZlKX2WXtHnzKa1U9Jz6C75fAwZRJ-CQ=.be9ff84a-bc34-4f4a-ab85-ba3c15aff500@github.com>

On Fri, 23 Sep 2022 12:41:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix JniVersion test
>
> This seems good.  I looked at the specification changes and they looked okay also.

Thanks @coleenp !

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From rrich at openjdk.org  Mon Sep 26 07:22:24 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 26 Sep 2022 07:22:24 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <cTFe5ly-5M7CylqOjvZKIPlleiyyNBzafMFKNv7l_dM=.f7578b58-7536-4efc-857b-64e56a40af1b@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
 <cTFe5ly-5M7CylqOjvZKIPlleiyyNBzafMFKNv7l_dM=.f7578b58-7536-4efc-857b-64e56a40af1b@github.com>
Message-ID: <7o6Op4sOWWcO55T_bIoJJSJWsGHsvX9G6fUxX-SRwSo=.bba202bd-2dbb-4197-a5b4-581ca3123070@github.com>

On Fri, 23 Sep 2022 19:01:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove `Unimplemented` definitions of interpreter_frame_last_sp
>
> I think it would be good to also have this looked at by someone from hotspot-runtime.  @coleenp, could you take a look?

Thanks for the review @dean-long

-------------

PR: https://git.openjdk.org/jdk/pull/9411

From dholmes at openjdk.org  Mon Sep 26 07:45:26 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Sep 2022 07:45:26 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
In-Reply-To: <54gu66M3RMXXgSJ59A4PK9MJSZl3edv1zm_CprRdWgU=.e6451425-3b77-4598-ad77-f27a61bcb255@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <64dBk9q9MnvwD6Zh4FTp8ASWNhBCKUwEO8bfA2vwYf8=.888197a2-3d6e-4407-81e7-267546c747dc@github.com>
 <54gu66M3RMXXgSJ59A4PK9MJSZl3edv1zm_CprRdWgU=.e6451425-3b77-4598-ad77-f27a61bcb255@github.com>
Message-ID: <t5OgHgQ5ROZvw4tQgIGnF8skH6kMX-b56BF34bbVcJQ=.39d1abb3-7d08-4c45-95ec-772389f5ecdf@github.com>

On Tue, 20 Sep 2022 12:44:48 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> So the time where (a) holds has lengthened, and the time that (b) holds has been shortened.

I'm surprised that @tstuefe does not object to this. Having some form of UL available during early initialization was a definite requirement from some people, so this seems a backward step in terms of functionality.

-------------

PR: https://git.openjdk.org/jdk/pull/10307

From duke at openjdk.org  Mon Sep 26 08:07:50 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 26 Sep 2022 08:07:50 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v6]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <GJ_UOC5wgFeegmrbrsUPo1VeaFWDELQwkUZMv_CGVJo=.ff7721d2-c80c-4106-9dca-ca5c8140d104@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/1149de31..73c99724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Mon Sep 26 08:07:51 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 26 Sep 2022 08:07:51 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v5]
In-Reply-To: <Ijaev_hEXN91s0kyh3Wi_XwQ3WsGlEB7We1OnNppuko=.7f2ef9d8-a45e-41c1-9f3b-ba05e2cb4855@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>
 <Ijaev_hEXN91s0kyh3Wi_XwQ3WsGlEB7We1OnNppuko=.7f2ef9d8-a45e-41c1-9f3b-ba05e2cb4855@github.com>
Message-ID: <_I0rVYnwm3aHArjqiTfgCviB1g1FAny6q0BabuLUKWg=.41255c7e-f0a0-4b62-95ed-2eb20430328a@github.com>

On Wed, 21 Sep 2022 16:49:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment
>
> test/jdk/tools/launcher/I18NArgTest.java line 152:
> 
>> 150:         }
>> 151:     }
>> 152: }
> 
> Nit: don't remove the newline at the end

I am sorry for my mistake. I fixed it.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From shade at openjdk.org  Mon Sep 26 08:52:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 08:52:33 GMT
Subject: RFR: 8293872: Make runtime/Thread/ThreadCountLimit.java more
 robust
In-Reply-To: <Bqyq7MaaAap7fld47mnHPNYUVvuROANr2NzM0NT6y0I=.328a17a7-3e5b-477d-8f8a-d42e6ee9d695@github.com>
References: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
 <jlMGFJ4Mw9rDHgfTiErmXmRSHnElxpvf-fIKAa3Ym1o=.975463a9-06f4-4168-b383-e758a8b9620e@github.com>
 <Bqyq7MaaAap7fld47mnHPNYUVvuROANr2NzM0NT6y0I=.328a17a7-3e5b-477d-8f8a-d42e6ee9d695@github.com>
Message-ID: <ihrXklt-GkI7UlUXuTj-rP-6P0TCkxv8FEkRXo3tnh8=.ab5a888a-840e-4730-87fc-38b72755edae@github.com>

On Wed, 21 Sep 2022 08:57:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > This seems fine. Thanks.
> 
> Thanks! Can I have another review?

Ping?

-------------

PR: https://git.openjdk.org/jdk/pull/10290

From dsamersoff at openjdk.org  Mon Sep 26 09:53:33 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 26 Sep 2022 09:53:33 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is
 set
Message-ID: <8Qu9RzE7KHG2f0vshbUPpWYmHDmiGnYsw4DtXTd1gM4=.d2657bd6-11a8-44f1-aea7-23cefe914729@github.com>

If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.

If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.

The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher. 

The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.

All relevant jtreg tests are passed.

-------------

Commit messages:
 - 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is set

Changes: https://git.openjdk.org/jdk/pull/10420/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293806
  Stats: 35 lines in 8 files changed: 11 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10420.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10420/head:pull/10420

PR: https://git.openjdk.org/jdk/pull/10420

From dsamersoff at openjdk.org  Mon Sep 26 10:16:30 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 26 Sep 2022 10:16:30 GMT
Subject: Withdrawn: 8293806: JDK_JAVA_OPTIONS picked up twice if
 LD_LIBRARY_PATH is set
In-Reply-To: <8Qu9RzE7KHG2f0vshbUPpWYmHDmiGnYsw4DtXTd1gM4=.d2657bd6-11a8-44f1-aea7-23cefe914729@github.com>
References: <8Qu9RzE7KHG2f0vshbUPpWYmHDmiGnYsw4DtXTd1gM4=.d2657bd6-11a8-44f1-aea7-23cefe914729@github.com>
Message-ID: <KKvYQL8HL5t6C6mH7i29RQPvfl8eb3CTeUft0x3DlUY=.de5873fc-3e11-4cf3-8f7b-93a37769ae24@github.com>

On Mon, 26 Sep 2022 09:46:36 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher. 
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10420

From jsjolen at openjdk.org  Mon Sep 26 10:23:17 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 26 Sep 2022 10:23:17 GMT
Subject: RFR: 8293873: Centralize the initialization of UL [v2]
In-Reply-To: <JyeGIy8X40O_2LHbOGnjzKFy_e2zgYhaMhcRrJDd_xc=.f44d9f0a-e1e4-42ea-b8f8-948326514b84@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
 <JyeGIy8X40O_2LHbOGnjzKFy_e2zgYhaMhcRrJDd_xc=.f44d9f0a-e1e4-42ea-b8f8-948326514b84@github.com>
Message-ID: <netLUNa_yjOeTR9R76l9pzb6cwa9kiMxjN6CYt_psKA=.c29a2c8d-2a84-49d5-bc59-5abfad2d05d7@github.com>

On Fri, 23 Sep 2022 13:47:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright years
>
> src/hotspot/share/logging/logFileStreamOutput.hpp line 77:
> 
>> 75:   LogStdoutOutput() : LogFileStreamOutput(stdout) {
>> 76:     set_config_string("all=warning");
>> 77:   }
> 
> Since you are here :-)
> 
> Wonder whether `_config_string` and `_config_string_buffer_size` could be replaced by an inline `stringStream,` and then we could save the awkward string shuffling in `set_config_string()` and `add_to_config_string()`.

We can do that, but it requires a larger move from buffer pointer + length to outputStream pointers in UL's API:s to be effective.

-------------

PR: https://git.openjdk.org/jdk/pull/10307

From adinn at openjdk.org  Mon Sep 26 12:33:18 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 26 Sep 2022 12:33:18 GMT
Subject: RFR: 8293872: Make runtime/Thread/ThreadCountLimit.java more
 robust
In-Reply-To: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
References: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
Message-ID: <VF407KK8QrhGYesmStGURQJpSSbIYHEKWAONi_en_A0=.e53a053c-fd65-4bf4-9e2b-59c9b5e4e87a@github.com>

On Thu, 15 Sep 2022 17:06:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am seeing this failure frequently on linux-x86:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
> ...
> stdout:
> [1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
> [1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
> # An error report file with more information is saved as:
> # /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
> [2.019s][warning][os ] Loading hsdis library failed
> 
> 
> It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.
> 
> I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.
> 
> Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.
> 
> After [JDK-8255450](https://bugs.openjdk.org/browse/JDK-8255450), this test still runs in tier2.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, affected test in 100 repetitions (all passed!)
>  - [x]  Linux x86_64 fastdebug, affected test in 100 repetitions

Looks good.

-------------

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10290

From shade at openjdk.org  Mon Sep 26 12:47:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 12:47:46 GMT
Subject: RFR: 8293872: Make runtime/Thread/ThreadCountLimit.java more
 robust
In-Reply-To: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
References: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
Message-ID: <PrI9F0HPh33dnLcc3WAZoSfhONHLQSfB0v2Otj5z6wk=.d6cea555-de43-44f9-a26e-b080c470ed19@github.com>

On Thu, 15 Sep 2022 17:06:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am seeing this failure frequently on linux-x86:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
> ...
> stdout:
> [1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
> [1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
> # An error report file with more information is saved as:
> # /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
> [2.019s][warning][os ] Loading hsdis library failed
> 
> 
> It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.
> 
> I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.
> 
> Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.
> 
> After [JDK-8255450](https://bugs.openjdk.org/browse/JDK-8255450), this test still runs in tier2.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, affected test in 100 repetitions (all passed!)
>  - [x]  Linux x86_64 fastdebug, affected test in 100 repetitions

Thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/10290

From shade at openjdk.org  Mon Sep 26 12:47:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 12:47:46 GMT
Subject: Integrated: 8293872: Make runtime/Thread/ThreadCountLimit.java more
 robust
In-Reply-To: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
References: <OgWH4snvKGQfjo54Oz54DJWchFQb9GIuhlXYC5eq5gI=.d3b6ba66-1ede-453a-b2be-343dcddec35f@github.com>
Message-ID: <VqCfcluFTnLqci0kgYKWxzp_AAItiJgaFzSNyyoWPO4=.f46cc201-591a-48d7-b323-1f5333fd9601@github.com>

On Thu, 15 Sep 2022 17:06:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am seeing this failure frequently on linux-x86:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
> ...
> stdout:
> [1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
> [1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
> # An error report file with more information is saved as:
> # /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
> [2.019s][warning][os ] Loading hsdis library failed
> 
> 
> It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.
> 
> I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.
> 
> Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.
> 
> After [JDK-8255450](https://bugs.openjdk.org/browse/JDK-8255450), this test still runs in tier2.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, affected test in 100 repetitions (all passed!)
>  - [x]  Linux x86_64 fastdebug, affected test in 100 repetitions

This pull request has now been integrated.

Changeset: 36b61c5d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36b61c5d7e7732924f494fa24c0e286e41279fc3
Stats:     49 lines in 1 file changed: 21 ins; 18 del; 10 mod

8293872: Make runtime/Thread/ThreadCountLimit.java more robust

Reviewed-by: dholmes, adinn

-------------

PR: https://git.openjdk.org/jdk/pull/10290

From shade at openjdk.org  Mon Sep 26 12:50:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 12:50:21 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <moTn68AhEfGrZMKlWQRD39kDDp-Kq0Vk4Y99q5gWodU=.5dbf84c8-428f-474b-87c8-141af8d4033c@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

I understand this is due to data race against unsynchronized writers? So only the partial fix from JDK-8293998 works, but not completely? If so, is there any way to strengthen the writers, so that we do not have to do this?

-------------

PR: https://git.openjdk.org/jdk/pull/10339

From mdoerr at openjdk.org  Mon Sep 26 14:34:08 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 26 Sep 2022 14:34:08 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <6lDB93qfMuQlqfSdAdhfsV2rYMBsOAIGYPOtQTVstwU=.d2b67e5c-2b77-40a9-9e52-154536bdc0bf@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

Adding release barriers at all places where we save the last Java sp and pc should also help. But that is mainly in assembly code which is spread over several files, not so nice to maintain and may have performance impact. I don' think it's worth the effort just to avoid extremely rare occurrences of last Java pc = 0. Dropping the sample makes more sense to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10339

From shade at openjdk.org  Mon Sep 26 14:37:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 14:37:35 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <XmJD5O9-r7n-NWVhE2zyoVHUcjrgqXWNwpCLC6t5Tj8=.361dafeb-f70d-40d0-bbf1-d87494805704@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

All right then. Yeah, the last time I looked at the anchor code that does this racily, it was not very nice to fix...

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10339

From mdoerr at openjdk.org  Mon Sep 26 14:37:36 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 26 Sep 2022 14:37:36 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <WncgPKDiYHVbeOD41eefAcnUngMExVWrdGQBXj4GL-M=.1e22ff2c-7c0f-48d1-a2a2-15135a64afb7@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

Thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/10339

From pchilanomate at openjdk.org  Mon Sep 26 15:40:56 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 26 Sep 2022 15:40:56 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
Message-ID: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>

Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/10424/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10424&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294370
  Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10424.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10424/head:pull/10424

PR: https://git.openjdk.org/jdk/pull/10424

From naoto at openjdk.org  Mon Sep 26 16:28:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Sep 2022 16:28:21 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v6]
In-Reply-To: <GJ_UOC5wgFeegmrbrsUPo1VeaFWDELQwkUZMv_CGVJo=.ff7721d2-c80c-4106-9dca-ca5c8140d104@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <GJ_UOC5wgFeegmrbrsUPo1VeaFWDELQwkUZMv_CGVJo=.ff7721d2-c80c-4106-9dca-ca5c8140d104@github.com>
Message-ID: <Kp_wtPAgXKa12VIwJt5bxUzoArDcUGWEdDhA-3Emm8E=.0a8678a9-1334-49d5-93b2-d8f2280fa80b@github.com>

On Mon, 26 Sep 2022 08:07:50 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Mon Sep 26 17:27:01 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Mon, 26 Sep 2022 17:27:01 GMT
Subject: RFR: 8293961: Unused ClassPathZipEntry::contents_do
Message-ID: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>

Removed unused function and ran tier1 to verify. Please review.

-------------

Commit messages:
 - 8293961: Unused ClassPathZipEntry::contents_do

Changes: https://git.openjdk.org/jdk/pull/10413/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293961
  Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10413.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10413/head:pull/10413

PR: https://git.openjdk.org/jdk/pull/10413

From duke at openjdk.org  Mon Sep 26 17:27:32 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Mon, 26 Sep 2022 17:27:32 GMT
Subject: RFR: 8293964: Unused check_for_duplicates parameter in
 ClassLoaderExt::process_jar_manifest
Message-ID: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>

The check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest was removed due to it being unused. Ran tier1 to verify. Please review

-------------

Commit messages:
 - 8293964: Unused check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest

Changes: https://git.openjdk.org/jdk/pull/10425/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293964
  Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10425.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10425/head:pull/10425

PR: https://git.openjdk.org/jdk/pull/10425

From dsamersoff at openjdk.org  Mon Sep 26 18:21:59 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 26 Sep 2022 18:21:59 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is
 set
Message-ID: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>

If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.

If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.

The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.

The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.

All relevant jtreg tests are passed.

-------------

Commit messages:
 - 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is set

Changes: https://git.openjdk.org/jdk/pull/10430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293806
  Stats: 35 lines in 8 files changed: 11 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10430.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10430/head:pull/10430

PR: https://git.openjdk.org/jdk/pull/10430

From sgehwolf at openjdk.org  Mon Sep 26 18:36:22 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 26 Sep 2022 18:36:22 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
Message-ID: <ygZLBTXC9VQXcAHTUPenyCWOiCbUBcdWIpa54mNJtxc=.bae5600c-d005-4997-8da6-fba098790434@github.com>

On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
>> 
>> 
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
>> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
>> 
>> 
>> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
>> 
>> Testing:
>> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
>> - [x] added tests fail before, pass after the product fix.
>> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
>> - [x] GHA all pass.
>> 
>> Please review! Many thanks in advance.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

@iklam Could you help me getting this reviewed, please?

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From ccheung at openjdk.org  Mon Sep 26 18:41:19 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 26 Sep 2022 18:41:19 GMT
Subject: RFR: 8293961: Unused ClassPathZipEntry::contents_do
In-Reply-To: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
References: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
Message-ID: <psKA3z8lRb2qYvJRnfDovbwUeHbePibxr1jkoVPZDLk=.d8cccb78-7369-4bcd-bfb4-5fde995dc45f@github.com>

On Fri, 23 Sep 2022 19:18:53 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Removed unused function and ran tier1 to verify. Please review.

Hi Matias,

The cleanup looks good. I think more cleanup could be done in classLoader.cpp.
Can you check if the following could be removed?


typedef jzentry* (*GetNextEntry_t)(jzfile *zip, jint n);

static GetNextEntry_t    GetNextEntry       = NULL;

  GetNextEntry = CAST_TO_FN_PTR(GetNextEntry_t, dll_lookup(_zip_handle, "ZIP_GetNextEntry", path));

Thanks,
Calvin

-------------

PR: https://git.openjdk.org/jdk/pull/10413

From ccheung at openjdk.org  Mon Sep 26 18:48:21 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 26 Sep 2022 18:48:21 GMT
Subject: RFR: 8293964: Unused check_for_duplicates parameter in
 ClassLoaderExt::process_jar_manifest
In-Reply-To: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
References: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
Message-ID: <uq3f_vq-wiFR0ev5IukFkx4qYfNX_MoK5z7jfVl6F-E=.cee988f1-d718-477d-ac00-89d3046f792a@github.com>

On Mon, 26 Sep 2022 15:21:07 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> The check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest was removed due to it being unused. Ran tier1 to verify. Please review

Looks good. Thanks.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10425

From duke at openjdk.org  Mon Sep 26 20:17:10 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Mon, 26 Sep 2022 20:17:10 GMT
Subject: RFR: 8293964: Unused check_for_duplicates parameter in
 ClassLoaderExt::process_jar_manifest [v2]
In-Reply-To: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
References: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
Message-ID: <lpLmn3JozyauGWChkXD4_rZ9KOtSbebxS_StqAe40Ck=.717267d0-0f79-4ae0-b2c0-656dbde70939@github.com>

> The check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest was removed due to it being unused. Ran tier1 to verify. Please review

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10425/files
  - new: https://git.openjdk.org/jdk/pull/10425/files/88a106fb..95167efa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10425&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10425&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10425.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10425/head:pull/10425

PR: https://git.openjdk.org/jdk/pull/10425

From dholmes at openjdk.org  Tue Sep 27 06:04:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 06:04:21 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <kXAQlXcudZELC5v1_dgJmccwdTwUPaXtBfz25rxNtd0=.e7c2815c-9b48-4314-aae5-53dabdaf8274@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Sorry @dsamersoff but I don't understand how this arises - can you explain in more detail please? I'm not seeing the connection between setting `LD_LIBRARY_PATH` and reading an env var twice. Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From dholmes at openjdk.org  Tue Sep 27 06:09:28 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 06:09:28 GMT
Subject: RFR: 8293964: Unused check_for_duplicates parameter in
 ClassLoaderExt::process_jar_manifest [v2]
In-Reply-To: <lpLmn3JozyauGWChkXD4_rZ9KOtSbebxS_StqAe40Ck=.717267d0-0f79-4ae0-b2c0-656dbde70939@github.com>
References: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
 <lpLmn3JozyauGWChkXD4_rZ9KOtSbebxS_StqAe40Ck=.717267d0-0f79-4ae0-b2c0-656dbde70939@github.com>
Message-ID: <NkQgtq_r5eYywv3r4MBDm5ikGD0pkpUPaENkw6Mk4nU=.b30119dd-8768-42df-b5d2-5e7eb2bd0de8@github.com>

On Mon, 26 Sep 2022 20:17:10 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

>> The check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest was removed due to it being unused. Ran tier1 to verify. Please review
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10425

From dholmes at openjdk.org  Tue Sep 27 06:22:46 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 06:22:46 GMT
Subject: RFR: 8294160: misc crash dump improvements
In-Reply-To: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
Message-ID: <O9Gmgaoj5eL4hRi7weSgiYymJvfvJ__l-5hD7jYnBzU=.128f7e42-c97c-4f94-b986-18fcadaf38fe@github.com>

On Thu, 22 Sep 2022 07:53:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> Try to recover and output meaningful information in more situations, such as:
> - when a pointer is in Method metadata memory range, but the memory is not committed
> - when we call a bad address
> 
> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.

I'm not familiar with all the aspects of this in enough detail so just a couple of observational comments.

src/hotspot/os/posix/signals_posix.cpp line 629:

> 627:   // Check for UD trap caused by NOP patching.
> 628:   // If it is, patch return address to be deopt handler.
> 629:   if (!signal_was_handled && pc != NULL && os::is_readable_pointer(pc)) {

If these new conditions are not met then what happens? What code will get the unreadable, or null pc to process?

src/hotspot/share/utilities/vmError.cpp line 353:

> 351: 
> 352:   // see if it's a valid frame
> 353:   if (fr.sp() != nullptr && os::is_readable_pointer(fr.sp())) {

Why did you completely change the notion of "valid frame" here?

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dholmes at openjdk.org  Tue Sep 27 06:52:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 06:52:13 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
In-Reply-To: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
Message-ID: <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com>

On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.
> 
> Thanks,
> Patricio

Good find! Looks good! A couple of queries at this stage.

Thanks.

src/hotspot/share/classfile/javaClasses.cpp line 2004:

> 2002:       const bool skip_hidden = !ShowHiddenFrames;
> 2003: 
> 2004:       // Pick some initial length

The comment should at least hint at there being some reasonable reason for choosing the value that follows. :)

src/hotspot/share/classfile/javaClasses.cpp line 2008:

> 2006:       _methods = new (ResourceObj::C_HEAP, mtInternal) GrowableArray<Method*>(init_length, mtInternal);
> 2007:       _bcis = new (ResourceObj::C_HEAP, mtInternal) GrowableArray<int>(init_length, mtInternal);
> 2008: 

Couldn't you just do this in the constructor? I'm not clear if there is a subtle reason for needing lazy-init as well as moving to the C_Heap.

-------------

PR: https://git.openjdk.org/jdk/pull/10424

From lucy at openjdk.org  Tue Sep 27 07:51:16 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 27 Sep 2022 07:51:16 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <WBJe8Z4C4jFyDfDwGvChM3L4YzcEh8btWNLa_i6vKX0=.f6f61fe4-2598-4361-b17e-abda3454ad61@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

Changes look good.

-------------

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10339

From mdoerr at openjdk.org  Tue Sep 27 07:55:17 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 27 Sep 2022 07:55:17 GMT
Subject: RFR: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <beT-LBBFxwkegngWnFsAlQ5_8ZjapuGq7B1zUQR1UuM=.6ee41135-ebfa-453f-978d-3d683b19c782@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

Thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/10339

From mdoerr at openjdk.org  Tue Sep 27 07:58:09 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 27 Sep 2022 07:58:09 GMT
Subject: Integrated: 8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr)
 failed: must have PC
In-Reply-To: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
References: <7YY_o-jtP1LnRmgKChltMT3M8UkrWeu2gUny73SsRiE=.04d59ea4-3677-49a0-9e62-235fb1f66804@github.com>
Message-ID: <yba19OzI5vJzrtv4wv8scc8gFaMsVjL0g1Jnimn8jpg=.f29a144f-f8a6-487f-b431-3eb62703bc2b@github.com>

On Mon, 19 Sep 2022 12:24:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JfrGetCallTrace can still observe last_Java_pc == 0 (see JBS for more details). We can just skip the sample in this very rare case.

This pull request has now been integrated.

Changeset: 14c6ac45
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14c6ac457d319a2e7f9cc9e7355c81c421a065dd
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8293998: [PPC64] JfrGetCallTrace: assert(_pc != nullptr) failed: must have PC

Reviewed-by: shade, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/10339

From dsamersoff at openjdk.org  Tue Sep 27 14:51:23 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 27 Sep 2022 14:51:23 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <kXAQlXcudZELC5v1_dgJmccwdTwUPaXtBfz25rxNtd0=.e7c2815c-9b48-4314-aae5-53dabdaf8274@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
 <kXAQlXcudZELC5v1_dgJmccwdTwUPaXtBfz25rxNtd0=.e7c2815c-9b48-4314-aae5-53dabdaf8274@github.com>
Message-ID: <UGrIzngLIULLl1fxU9PqMkm3Rocxn4qa4zD2Tz93JRU=.9b786a2d-c284-4c2d-97fd-2d3c8afb0303@github.com>

On Tue, 27 Sep 2022 06:00:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry @dsamersoff but I don't understand how this arises - can you explain in more detail please? I'm not seeing the connection between setting `LD_LIBRARY_PATH` and reading an env var twice. Thanks

Linker read LD_LIBRARY_PATH only once, at the time of program loading, so if for some reason launcher need to update LD_LIBRARY_PATH, it creates a new environment and re-launch it self using execvp(). 

But the launcher is designed so that the decision to re-launch is made after all arguments from all sources have already been processed and copied to the argv array.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From duke at openjdk.org  Tue Sep 27 15:42:50 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Tue, 27 Sep 2022 15:42:50 GMT
Subject: Integrated: 8293964: Unused check_for_duplicates parameter in
 ClassLoaderExt::process_jar_manifest
In-Reply-To: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
References: <cgz6x4v68gd48wP59YWyFtalVPfijtng2bkk5HIll-g=.5bb4db6f-9c55-4316-84ef-8b2bf9f4e54e@github.com>
Message-ID: <PC-fKzDfm-s_kVZt-2iF6aBhELvUGmatDgGwEDD2QH8=.0771909c-f934-4416-a942-4a5405592c76@github.com>

On Mon, 26 Sep 2022 15:21:07 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> The check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest was removed due to it being unused. Ran tier1 to verify. Please review

This pull request has now been integrated.

Changeset: 112ca2b8
Author:    Matias Saavedra Silva <matias.s.saavedra.silva at oracle.com>
Committer: Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/112ca2b863e3caf647645eebd87423925a271e3e
Stats:     4 lines in 3 files changed: 0 ins; 1 del; 3 mod

8293964: Unused check_for_duplicates parameter in ClassLoaderExt::process_jar_manifest

Reviewed-by: ccheung, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/10425

From duke at openjdk.org  Tue Sep 27 16:07:35 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 27 Sep 2022 16:07:35 GMT
Subject: Integrated: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <Q-AiUyxg6BhmeTABPqaMl6XuvhVSiLtCUTRxqJD3Wv4=.29a8cc15-be64-47a0-9064-df7ea80a73b0@github.com>

On Wed, 6 Jul 2022 06:40:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

This pull request has now been integrated.

Changeset: a11477ce
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a11477ce259d6d2a053117a2300ebb171145cfde
Stats:     51 lines in 1 file changed: 26 ins; 3 del; 22 mod

8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From pchilanomate at openjdk.org  Tue Sep 27 16:11:24 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 27 Sep 2022 16:11:24 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
In-Reply-To: <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
 <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com>
Message-ID: <sjusGg6DAeA4WLBS8AyYtnDCKKwZc1ITKK0DNb8powc=.fe1b4d35-6bf7-4ee9-972a-91f6cd58db35@github.com>

On Tue, 27 Sep 2022 06:48:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Good find! Looks good! A couple of queries at this stage.
> 
> Thanks.
>
Thanks for looking at this David.

> src/hotspot/share/classfile/javaClasses.cpp line 2004:
> 
>> 2002:       const bool skip_hidden = !ShowHiddenFrames;
>> 2003: 
>> 2004:       // Pick some initial length
> 
> The comment should at least hint at there being some reasonable reason for choosing the value that follows. :)

How about: "Pick minimum length that will cover most cases"?

> src/hotspot/share/classfile/javaClasses.cpp line 2008:
> 
>> 2006:       _methods = new (ResourceObj::C_HEAP, mtInternal) GrowableArray<Method*>(init_length, mtInternal);
>> 2007:       _bcis = new (ResourceObj::C_HEAP, mtInternal) GrowableArray<int>(init_length, mtInternal);
>> 2008: 
> 
> Couldn't you just do this in the constructor? I'm not clear if there is a subtle reason for needing lazy-init as well as moving to the C_Heap.

Yes, this could have been done in the constructor too. But since there are additional checks in the closure that could fail I move the allocation here to avoid unnecessary allocation/deallocation. The allocation still needs to be done in the C_Heap in case the target executes the handshake. Otherwise if the target allocates the arrays in its resource area they could be deallocated by the time the requester tries to access them after the handshake.

-------------

PR: https://git.openjdk.org/jdk/pull/10424

From gziemski at openjdk.org  Tue Sep 27 16:26:29 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 27 Sep 2022 16:26:29 GMT
Subject: RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC
In-Reply-To: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
References: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
Message-ID: <kqTyQ76u5KKSnXV8hncQz1F_9lx4kuhZ2rk9EI6mKuY=.32175ed1-7e93-4b02-a5f1-bc2e53c488a3@github.com>

On Wed, 27 Jul 2022 19:19:44 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> O_CLOEXEC is also available on macOS (__DARWIN_C_LEVEL >= 200809L), so use it same as on linux.

> What you _could_ do and what would be helpful is a very primitive gtest that tests that files opened with os::open are correctly tagged with FD_CLOEXEC.

I like that.

-------------

PR: https://git.openjdk.org/jdk/pull/9663

From gziemski at openjdk.org  Tue Sep 27 16:30:46 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 27 Sep 2022 16:30:46 GMT
Subject: Integrated: 8289162: runtime/NMT/ThreadedMallocTestType.java should
 print out memory allocations to help debug
In-Reply-To: <hDY6VU8V0iHamC_5yD85pvlWxsYFVvvtgo3l28cXXCo=.23a9a069-bc89-47c9-ad35-b97938712d88@github.com>
References: <hDY6VU8V0iHamC_5yD85pvlWxsYFVvvtgo3l28cXXCo=.23a9a069-bc89-47c9-ad35-b97938712d88@github.com>
Message-ID: <qT3v1oQ1z0N5pH-HHDFUrL_pl4gEAXAjrJThehJzPj0=.d12fdcc2-cde5-4292-b90d-d900737d97b5@github.com>

On Thu, 28 Jul 2022 14:42:26 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> To help debug [JDK-8286345](https://bugs.openjdk.org/browse/JDK-8286345) it would have been extremely useful to know the values of allocated memory pointers in `runtime/NMT/ThreadedMallocTestType.java`, so let's add those.

This pull request has now been integrated.

Changeset: 739fdec7
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/739fdec7ea44be7ab12fdf418793276d581e58fe
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8289162: runtime/NMT/ThreadedMallocTestType.java should print out memory allocations to help debug

Reviewed-by: hseigel, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/9675

From duke at openjdk.org  Tue Sep 27 17:45:29 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Tue, 27 Sep 2022 17:45:29 GMT
Subject: RFR: 8293961: Unused ClassPathZipEntry::contents_do [v2]
In-Reply-To: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
References: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
Message-ID: <OFfqNqmSE1Sp6i5NpyY9iSS_XUiWe1XCXREU0LMhHAY=.da51b7ae-5102-4034-ab6c-f98e7f7f3da3@github.com>

> Removed unused function and ran tier1 to verify. Please review.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Deleted unused GetNextEntry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10413/files
  - new: https://git.openjdk.org/jdk/pull/10413/files/5fea8938..b3b75758

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10413&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10413&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10413.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10413/head:pull/10413

PR: https://git.openjdk.org/jdk/pull/10413

From duke at openjdk.org  Tue Sep 27 17:45:31 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Tue, 27 Sep 2022 17:45:31 GMT
Subject: RFR: 8293961: Unused ClassPathZipEntry::contents_do
In-Reply-To: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
References: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
Message-ID: <9kvBNI5Y2Bcu-AO9lsc9mwV47VtSmd8GTWD02PBAKl0=.443994fd-710f-4ebe-9e94-4b6bca81113a@github.com>

On Fri, 23 Sep 2022 19:18:53 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Removed unused function and ran tier1 to verify. Please review.

The code you posted could indeed be removed. I verified that everything still works with tier 1 tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10413

From dlong at openjdk.org  Tue Sep 27 18:22:27 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 27 Sep 2022 18:22:27 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
Message-ID: <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>

> Try to recover and output meaningful information in more situations, such as:
> - when a pointer is in Method metadata memory range, but the memory is not committed
> - when we call a bad address
> 
> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  revert unneeded changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10387/files
  - new: https://git.openjdk.org/jdk/pull/10387/files/a06a47a2..ec02ee5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10387&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10387&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10387.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10387/head:pull/10387

PR: https://git.openjdk.org/jdk/pull/10387

From dlong at openjdk.org  Tue Sep 27 18:22:29 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 27 Sep 2022 18:22:29 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <O9Gmgaoj5eL4hRi7weSgiYymJvfvJ__l-5hD7jYnBzU=.128f7e42-c97c-4f94-b986-18fcadaf38fe@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <O9Gmgaoj5eL4hRi7weSgiYymJvfvJ__l-5hD7jYnBzU=.128f7e42-c97c-4f94-b986-18fcadaf38fe@github.com>
Message-ID: <YV01fCHvJIzDupjesByP7S5ZPGtmFfE5SAwchDSARzY=.a3afb494-bbb0-4c2e-9b4b-bee5054c4ece@github.com>

On Tue, 27 Sep 2022 06:19:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert unneeded changes
>
> src/hotspot/share/utilities/vmError.cpp line 353:
> 
>> 351: 
>> 352:   // see if it's a valid frame
>> 353:   if (fr.sp() != nullptr && os::is_readable_pointer(fr.sp())) {
> 
> Why did you completely change the notion of "valid frame" here?

I needed for an early version of the patch, but I can remove it now.  Using sp() instead of pc() could possibly give more progress on weird native frames, and is_readable_pointer() prevents some crashes during stack walking.

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dlong at openjdk.org  Tue Sep 27 18:29:36 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 27 Sep 2022 18:29:36 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <O9Gmgaoj5eL4hRi7weSgiYymJvfvJ__l-5hD7jYnBzU=.128f7e42-c97c-4f94-b986-18fcadaf38fe@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <O9Gmgaoj5eL4hRi7weSgiYymJvfvJ__l-5hD7jYnBzU=.128f7e42-c97c-4f94-b986-18fcadaf38fe@github.com>
Message-ID: <3pS8F7UlVwR__31U1S3BWdZovmm0UASYXAQZYyEa5_0=.51600186-bdc0-4803-abb8-ce74683ab11d@github.com>

On Tue, 27 Sep 2022 06:17:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert unneeded changes
>
> src/hotspot/os/posix/signals_posix.cpp line 629:
> 
>> 627:   // Check for UD trap caused by NOP patching.
>> 628:   // If it is, patch return address to be deopt handler.
>> 629:   if (!signal_was_handled && pc != NULL && os::is_readable_pointer(pc)) {
> 
> If these new conditions are not met then what happens? What code will get the unreadable, or null pc to process?

It will fall through and treat the signal as unhandled, resulting in a crash dump.  The old code was wrong for these reasons:

- It would assert in the signal handler if PC was 0
- It would crash in the signal handler if PC was not in readable memory
- It ignored the previously adjusted value of PC, which means trap-based NOP patching probably wouldn't have worked on platforms that need the PC adjusted, like s390

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From ccheung at openjdk.org  Tue Sep 27 18:47:21 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 27 Sep 2022 18:47:21 GMT
Subject: RFR: 8293961: Unused ClassPathZipEntry::contents_do [v2]
In-Reply-To: <OFfqNqmSE1Sp6i5NpyY9iSS_XUiWe1XCXREU0LMhHAY=.da51b7ae-5102-4034-ab6c-f98e7f7f3da3@github.com>
References: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
 <OFfqNqmSE1Sp6i5NpyY9iSS_XUiWe1XCXREU0LMhHAY=.da51b7ae-5102-4034-ab6c-f98e7f7f3da3@github.com>
Message-ID: <_IViod0jToTgyIuHF047kXulDfoBVyPySGYDo8H62XI=.9ed4a9d5-86a6-4ec8-9bcd-e7419690de25@github.com>

On Tue, 27 Sep 2022 17:45:29 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

>> Removed unused function and ran tier1 to verify. Please review.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted unused GetNextEntry

Updated fix looks good. Thanks.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10413

From dholmes at openjdk.org  Tue Sep 27 21:04:17 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 21:04:17 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <9pX9wo9D-gVHNXKeLMZz4bOwLy-qKjXMQmsJKMSUQo8=.bdca5133-26d9-439a-b079-c3c257065ad2@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Can't we just remove `JDK_JAVA_OPTIONS` from the new env in that case?

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From dholmes at openjdk.org  Tue Sep 27 23:46:15 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 23:46:15 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
Message-ID: <TGc8WDnb4FDB6zNgjsouj9SM1CYk8_7rlEoEmpZF3fg=.5fa04872-0da5-4f0b-9289-9b829947e7c1@github.com>

On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
>> 
>> JDK-8290196 12.8: Clarify the definition of program exit
>> https://bugs.openjdk.org/browse/JDK-8290196
>> 
>> JDK-8290388 5.7: Clarify the definition of JVM termination
>> https://bugs.openjdk.org/browse/JDK-8290388
>> 
>> JDK-8290036 Define and specify Runtime shutdown sequence
>> https://bugs.openjdk.org/browse/JDK-8290036
>> 
>> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
>> 
>> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
>> 
>> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
>> 
>> Issue 2 covers the code change, and regression test, in this PR.
>> 
>> In addition the specification changes can be seen here:
>> 
>> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
>> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
>> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
>> 
>> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
>> 
>> Thank you.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JniVersion test

CSR is now approved.

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From dholmes at openjdk.org  Wed Sep 28 00:01:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 00:01:58 GMT
Subject: Integrated: 8290482: Update JNI Specification of DestroyJavaVM for
 better alignment with JLS, JVMS, and Java SE API Specifications
In-Reply-To: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
Message-ID: <H8mdReVLkGmcmH7K7kZjKPm7AlXqDQpnyUPAiABQS_8=.f20774b0-8c55-4df4-8592-7ab191d17077@github.com>

On Tue, 20 Sep 2022 00:55:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
> 
> JDK-8290196 12.8: Clarify the definition of program exit
> https://bugs.openjdk.org/browse/JDK-8290196
> 
> JDK-8290388 5.7: Clarify the definition of JVM termination
> https://bugs.openjdk.org/browse/JDK-8290388
> 
> JDK-8290036 Define and specify Runtime shutdown sequence
> https://bugs.openjdk.org/browse/JDK-8290036
> 
> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
> 
> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
> 
> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
> 
> Issue 2 covers the code change, and regression test, in this PR.
> 
> In addition the specification changes can be seen here:
> 
> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
> 
> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
> 
> Thank you.

This pull request has now been integrated.

Changeset: e5b65c40
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5b65c40ea032c6955311593e02ed44f14dfe80a
Stats:     112 lines in 6 files changed: 108 ins; 1 del; 3 mod

8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications

Reviewed-by: rehn, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From dholmes at openjdk.org  Wed Sep 28 01:22:12 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 01:22:12 GMT
Subject: RFR: 8293961: Unused ClassPathZipEntry::contents_do [v2]
In-Reply-To: <OFfqNqmSE1Sp6i5NpyY9iSS_XUiWe1XCXREU0LMhHAY=.da51b7ae-5102-4034-ab6c-f98e7f7f3da3@github.com>
References: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
 <OFfqNqmSE1Sp6i5NpyY9iSS_XUiWe1XCXREU0LMhHAY=.da51b7ae-5102-4034-ab6c-f98e7f7f3da3@github.com>
Message-ID: <bvfGALmzTmYNaZLJX3ULpxBTKFOnMD3oz0-1loRWCmM=.fb726a9c-ad44-4e06-8625-22366c3addb4@github.com>

On Tue, 27 Sep 2022 17:45:29 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

>> Removed unused function and ran tier1 to verify. Please review.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted unused GetNextEntry

LGTM2

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10413

From dholmes at openjdk.org  Wed Sep 28 01:28:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 01:28:05 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
Message-ID: <hTJgtOCgYtMb8hzIqOsvpowPMZXOjiriihyTZofD6_M=.5b4bc388-c32a-4882-abd5-c839ca4d2d74@github.com>

On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Try to recover and output meaningful information in more situations, such as:
>> - when a pointer is in Method metadata memory range, but the memory is not committed
>> - when we call a bad address
>> 
>> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unneeded changes

src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 357:

> 355:   // point to garbage if entry point in an nmethod is corrupted. Leave
> 356:   // this at the end, and hope for the best.
> 357:   address pc = os::fetch_frame_from_context(uc).pc();

What is the difference between `ucontext_get_pc(uc)` and getting the pc from the frame from the uc? How many pc's can a ucontext have?

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dholmes at openjdk.org  Wed Sep 28 01:59:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 01:59:18 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
In-Reply-To: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
Message-ID: <dpSWoVsdbPx5INF4-RFCPPwhornFnYL1nM0OhNC524Q=.f890b081-d681-454a-8404-ff6370713557@github.com>

On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.
> 
> Thanks,
> Patricio

Looks good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10424

From dholmes at openjdk.org  Wed Sep 28 01:59:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 01:59:21 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
In-Reply-To: <sjusGg6DAeA4WLBS8AyYtnDCKKwZc1ITKK0DNb8powc=.fe1b4d35-6bf7-4ee9-972a-91f6cd58db35@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
 <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com>
 <sjusGg6DAeA4WLBS8AyYtnDCKKwZc1ITKK0DNb8powc=.fe1b4d35-6bf7-4ee9-972a-91f6cd58db35@github.com>
Message-ID: <affvd_fsDMzDhrWhZSs1DUyEc-D5GPEXxRh0k0Ge3rs=.301006f1-3d4a-4c7a-8c22-f32c4f60b979@github.com>

On Tue, 27 Sep 2022 16:09:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2004:
>> 
>>> 2002:       const bool skip_hidden = !ShowHiddenFrames;
>>> 2003: 
>>> 2004:       // Pick some initial length
>> 
>> The comment should at least hint at there being some reasonable reason for choosing the value that follows. :)
>
> How about: "Pick minimum length that will cover most cases"?

Sounds good.

>> src/hotspot/share/classfile/javaClasses.cpp line 2008:
>> 
>>> 2006:       _methods = new (ResourceObj::C_HEAP, mtInternal) GrowableArray<Method*>(init_length, mtInternal);
>>> 2007:       _bcis = new (ResourceObj::C_HEAP, mtInternal) GrowableArray<int>(init_length, mtInternal);
>>> 2008: 
>> 
>> Couldn't you just do this in the constructor? I'm not clear if there is a subtle reason for needing lazy-init as well as moving to the C_Heap.
>
> Yes, this could have been done in the constructor too. But since there are additional checks in the closure that could fail I move the allocation here to avoid unnecessary allocation/deallocation. The allocation still needs to be done in the C_Heap in case the target executes the handshake. Otherwise if the target allocates the arrays in its resource area they could be deallocated by the time the requester tries to access them after the handshake.

Good point - only allocate when known to be needed.

-------------

PR: https://git.openjdk.org/jdk/pull/10424

From dlong at openjdk.org  Wed Sep 28 04:06:21 2022
From: dlong at openjdk.org (Dean Long)
Date: Wed, 28 Sep 2022 04:06:21 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <hTJgtOCgYtMb8hzIqOsvpowPMZXOjiriihyTZofD6_M=.5b4bc388-c32a-4882-abd5-c839ca4d2d74@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
 <hTJgtOCgYtMb8hzIqOsvpowPMZXOjiriihyTZofD6_M=.5b4bc388-c32a-4882-abd5-c839ca4d2d74@github.com>
Message-ID: <2yNRptjzAcFlrRBBJVGxiQYvPB2WvS8FQZVlfYxesVs=.3e37f094-4e37-4090-a7de-6920ed2ac521@github.com>

On Wed, 28 Sep 2022 01:24:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert unneeded changes
>
> src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 357:
> 
>> 355:   // point to garbage if entry point in an nmethod is corrupted. Leave
>> 356:   // this at the end, and hope for the best.
>> 357:   address pc = os::fetch_frame_from_context(uc).pc();
> 
> What is the difference between `ucontext_get_pc(uc)` and getting the pc from the frame from the uc? How many pc's can a ucontext have?

The former returns the PC where the crash happened, which could be in unreadable memory.  Blindly inspecting that memory will cause error reporting to crash.  The latter returns the PC of a frame constructed from the context, and _possibly adjusted to reflect where the caller was when it made the bad call_, which is more useful for getting stack backtraces and less likely to crash error reporting.  When error reporting crashes we recover, but we don't get the information it was dumping when it crashed.

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dholmes at openjdk.org  Wed Sep 28 04:27:25 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 04:27:25 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
Message-ID: <4g49q1iwkeMPS34OR_y3w4iV0o4J6OvcStEUWz2jSec=.61b0a015-4369-4116-8f40-575072ec5588@github.com>

On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Try to recover and output meaningful information in more situations, such as:
>> - when a pointer is in Method metadata memory range, but the memory is not committed
>> - when we call a bad address
>> 
>> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unneeded changes

Okay seems quite reasonable. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10387

From sspitsyn at openjdk.org  Wed Sep 28 04:45:22 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 Sep 2022 04:45:22 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
In-Reply-To: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
Message-ID: <EvNDg3Dy4f7DwPSPXApvSHipfL1FxQzWa4b9zfdMviw=.eb7f2ce9-806d-4aba-ab6c-62ddf1ba5ec6@github.com>

On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.
> 
> Thanks,
> Patricio

Yes, it is good find!
The fix looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10424

From iklam at openjdk.org  Wed Sep 28 05:47:46 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 Sep 2022 05:47:46 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
Message-ID: <TJY2GKBQMw6V9Fi1LgT2hnyOdaiziTeHNAz7_NR2Zo8=.bc9e32d9-1d33-436e-b5fd-1658c6f319d1@github.com>

On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
>> 
>> 
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
>> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
>> 
>> 
>> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
>> 
>> Testing:
>> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
>> - [x] added tests fail before, pass after the product fix.
>> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
>> - [x] GHA all pass.
>> 
>> Please review! Many thanks in advance.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

The JDK change looks good to me. Some nits for the test cases.

test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @summary Verify that -XshowSettings:system works

Add `@bug 8293540`

test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64:

> 62:         opts.addDockerOpts("--memory", "300m");
> 63:         if (addCgroupMounts) {
> 64:             opts.addDockerOpts("--volume", "/sys/fs/cgroup:/cgroup-in:ro");

Add comments that the extra mount should be ignored by the cgroup set-up code. (Same for other test cases).

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10248

From dlong at openjdk.org  Wed Sep 28 06:41:30 2022
From: dlong at openjdk.org (Dean Long)
Date: Wed, 28 Sep 2022 06:41:30 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
Message-ID: <zZ3j5LR0OvDuaVITqF21IDcRtFfkH3RZu2H9jrKsMbA=.6fde0b96-d3a4-40d8-a820-4601c98061a9@github.com>

On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Try to recover and output meaningful information in more situations, such as:
>> - when a pointer is in Method metadata memory range, but the memory is not committed
>> - when we call a bad address
>> 
>> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unneeded changes

Thanks David.

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dsamersoff at openjdk.org  Wed Sep 28 09:48:22 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Wed, 28 Sep 2022 09:48:22 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <Rb-Rv_ZGP2OhYPneYO40X4LSX21utYlRNAorLnUABt8=.7690084a-79a6-4625-b431-cd6051094e2e@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

> 
Unfortunately not. 
Java application (like IDE) may rely on JDK_JAVA_OPTIONS variable to pass Java options to it's child processes.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From duke at openjdk.org  Wed Sep 28 13:28:06 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Wed, 28 Sep 2022 13:28:06 GMT
Subject: RFR: 8293969: breakup the long signature in
 SystemDictionaryShared::is_supported_invokedynamic
Message-ID: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>

Broke up signature into three lines. Tested with tier 1. Please review

-------------

Commit messages:
 - 8293969: breakup the long signature in SystemDictionaryShared::is_supported_invokedynamic

Changes: https://git.openjdk.org/jdk/pull/10452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293969
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10452.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10452/head:pull/10452

PR: https://git.openjdk.org/jdk/pull/10452

From eastigeevich at openjdk.org  Wed Sep 28 14:06:07 2022
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 28 Sep 2022 14:06:07 GMT
Subject: RFR: 8293969: breakup the long signature in
 SystemDictionaryShared::is_supported_invokedynamic
In-Reply-To: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>
References: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>
Message-ID: <59KKJLYXmkmTaSLKu-DUu-jlKFjv7hD9BgKnX_nD5Ew=.dc1ea826-1b83-4343-927f-7d57f4114ebb@github.com>

On Tue, 27 Sep 2022 15:44:30 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Broke up signature into three lines. Tested with tier 1. Please review

lgtm

-------------

Marked as reviewed by eastigeevich (Committer).

PR: https://git.openjdk.org/jdk/pull/10452

From pchilanomate at openjdk.org  Wed Sep 28 14:43:43 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 28 Sep 2022 14:43:43 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace() [v2]
In-Reply-To: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
Message-ID: <0WKocsH7YOhswIyiLidi6eyr-xqrGwLCIBo32VN7HO4=.24a710c3-f767-4474-a0c9-ac6ff79fea36@github.com>

> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10424/files
  - new: https://git.openjdk.org/jdk/pull/10424/files/5e375a83..68486d1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10424&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10424&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10424.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10424/head:pull/10424

PR: https://git.openjdk.org/jdk/pull/10424

From pchilanomate at openjdk.org  Wed Sep 28 14:46:33 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 28 Sep 2022 14:46:33 GMT
Subject: RFR: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace() [v2]
In-Reply-To: <0WKocsH7YOhswIyiLidi6eyr-xqrGwLCIBo32VN7HO4=.24a710c3-f767-4474-a0c9-ac6ff79fea36@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
 <0WKocsH7YOhswIyiLidi6eyr-xqrGwLCIBo32VN7HO4=.24a710c3-f767-4474-a0c9-ac6ff79fea36@github.com>
Message-ID: <RtRljVsJWRjLKz3nHnElYneKgNxHU_GNdosOGsWnveo=.950e83c5-0c48-4c09-bd0f-6914f9475d03@github.com>

On Wed, 28 Sep 2022 14:43:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
>> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
>> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
>> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Thanks for the reviews David and Serguei!

-------------

PR: https://git.openjdk.org/jdk/pull/10424

From duke at openjdk.org  Wed Sep 28 16:02:56 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Wed, 28 Sep 2022 16:02:56 GMT
Subject: Integrated: 8293961: Unused ClassPathZipEntry::contents_do
In-Reply-To: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
References: <0z3WHk2IOOu4ENe2sVOO2-tTKgzUPWgV2AVozZktrqY=.387f1bcc-f1ac-4d34-8ce3-30a81995c1b1@github.com>
Message-ID: <CGcgf15XtvFHsHBdICJ30ZOsKw8hZZV1aNWRemt4Wns=.21f7dbe7-a3a3-449b-a919-865190c439f8@github.com>

On Fri, 23 Sep 2022 19:18:53 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Removed unused function and ran tier1 to verify. Please review.

This pull request has now been integrated.

Changeset: 4fb424ba
Author:    Matias Saavedra Silva <matias.s.saavedra.silva at oracle.com>
Committer: Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fb424ba5f3ece1a47b8774defdbe6645cc72759
Stats:     16 lines in 2 files changed: 0 ins; 16 del; 0 mod

8293961: Unused ClassPathZipEntry::contents_do

Reviewed-by: ccheung, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/10413

From gziemski at openjdk.org  Wed Sep 28 17:21:53 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 28 Sep 2022 17:21:53 GMT
Subject: RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC
 [v2]
In-Reply-To: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
References: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
Message-ID: <5rmdnfrygi8Fmz9OBA8Bd1OebPJSgVKG1G4SyuapMwY=.54415438-2a31-4645-8899-06eace1a1ef1@github.com>

> O_CLOEXEC is also available on macOS (__DARWIN_C_LEVEL >= 200809L), so use it same as on linux.

Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:

 - add test to verify that open(O_CLOEXEC) implies FD_CLOEXEC on macOS
 - assume O_CLOEXEC on macOS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9663/files
  - new: https://git.openjdk.org/jdk/pull/9663/files/7628e09a..82d1bbad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9663&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9663&range=00-01

  Stats: 33 lines in 2 files changed: 10 ins; 20 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9663.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9663/head:pull/9663

PR: https://git.openjdk.org/jdk/pull/9663

From gziemski at openjdk.org  Wed Sep 28 17:24:43 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 28 Sep 2022 17:24:43 GMT
Subject: RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC
 [v2]
In-Reply-To: <5rmdnfrygi8Fmz9OBA8Bd1OebPJSgVKG1G4SyuapMwY=.54415438-2a31-4645-8899-06eace1a1ef1@github.com>
References: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
 <5rmdnfrygi8Fmz9OBA8Bd1OebPJSgVKG1G4SyuapMwY=.54415438-2a31-4645-8899-06eace1a1ef1@github.com>
Message-ID: <R1JRy0PBsZ7X5sN6yxjUCC8xMPaZoFRoyU0BPLVX5WI=.7184dcc3-207c-402c-83a5-16ac053afca9@github.com>

On Wed, 28 Sep 2022 17:21:53 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> O_CLOEXEC is also available on macOS (__DARWIN_C_LEVEL >= 200809L), so use it same as on linux.
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add test to verify that open(O_CLOEXEC) implies FD_CLOEXEC on macOS
>  - assume O_CLOEXEC on macOS

Followed feedback from David and Thomas.

We now assume that `O_CLOEXEC` is available on macOS, but we added `__APPLE__` gtest that verifies that assumption via:

`make run-test TEST=gtest:os.open_O_CLOEXEC`

-------------

PR: https://git.openjdk.org/jdk/pull/9663

From vlivanov at openjdk.org  Wed Sep 28 21:31:33 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 28 Sep 2022 21:31:33 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
Message-ID: <2XNlpaadktynPmtoquJJX9Fq9LjLRamKilcku1yHRa8=.4ecb796f-311a-4596-b5f9-f42c3ab14072@github.com>

On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Try to recover and output meaningful information in more situations, such as:
>> - when a pointer is in Method metadata memory range, but the memory is not committed
>> - when we call a bad address
>> 
>> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unneeded changes

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10387

From dlong at openjdk.org  Wed Sep 28 23:16:24 2022
From: dlong at openjdk.org (Dean Long)
Date: Wed, 28 Sep 2022 23:16:24 GMT
Subject: RFR: 8294160: misc crash dump improvements [v2]
In-Reply-To: <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
 <JbeX_sgKmDF4r90QJ3Q1SAMpIqi72Yh6bYlRpX2KC4A=.b020fa7c-df35-4e56-a8bd-9ebad5ecd8b1@github.com>
Message-ID: <csWSqtwolFq7p539VREEjqLmGy6lYeYlY8AKGg0LWug=.c63f4888-77a9-4f41-934b-63af5e5b3de3@github.com>

On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Try to recover and output meaningful information in more situations, such as:
>> - when a pointer is in Method metadata memory range, but the memory is not committed
>> - when we call a bad address
>> 
>> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unneeded changes

Thanks Vladimir.

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dlong at openjdk.org  Wed Sep 28 23:17:47 2022
From: dlong at openjdk.org (Dean Long)
Date: Wed, 28 Sep 2022 23:17:47 GMT
Subject: Integrated: 8294160: misc crash dump improvements
In-Reply-To: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
References: <jdXdF4hUVyRw5-r3AX4DP6zZHKQG2F3A6JKolHKO-W0=.cfaf24f0-82ee-4e38-bf30-ad4f584af8c0@github.com>
Message-ID: <ErVSzSt4gNE_ISsat9zKdkMvee9Hikh0fmfbGgsuBxA=.67b5cedf-d387-46f1-8ce3-603e0e30b135@github.com>

On Thu, 22 Sep 2022 07:53:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> Try to recover and output meaningful information in more situations, such as:
> - when a pointer is in Method metadata memory range, but the memory is not committed
> - when we call a bad address
> 
> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.

This pull request has now been integrated.

Changeset: 6f8f28e7
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f8f28e7566701b195ecc855f3e802cd7145e9aa
Stats:     26 lines in 5 files changed: 20 ins; 2 del; 4 mod

8294160: misc crash dump improvements

Reviewed-by: dholmes, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/10387

From dholmes at openjdk.org  Thu Sep 29 04:53:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Sep 2022 04:53:24 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <OoWqswpfjk7H1mUUn5R5RGc7f94AwDLKloZoejSBynw=.e797e828-ad87-423d-b19f-3dc33c127fb4@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Sorry Dmitry I'm still trying to get my head around the big picture here. The launcher startup process is extremely complex but also quite sophisticated so I'm a bit surprised this issue exists (and that we have not noticed it before!). I have an impression that the intent if we re-exec is that the env var options have already been processed and so the newly exec'd `java` is not supposed to process them again (they have already been converted to items in `argv`) - see `JLI_AddArgsFromEnvVar` and the use of the `relaunch` field. It seems quite redundant to have the exec'd `java` repeat all the arg processing that has already taken place. 

I'm also struggling to understand under what conditions, exactly, we will re-exec when the data-model selection is no longer an issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From dholmes at openjdk.org  Thu Sep 29 07:51:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Sep 2022 07:51:18 GMT
Subject: RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC
 [v2]
In-Reply-To: <5rmdnfrygi8Fmz9OBA8Bd1OebPJSgVKG1G4SyuapMwY=.54415438-2a31-4645-8899-06eace1a1ef1@github.com>
References: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
 <5rmdnfrygi8Fmz9OBA8Bd1OebPJSgVKG1G4SyuapMwY=.54415438-2a31-4645-8899-06eace1a1ef1@github.com>
Message-ID: <G37nhOSFoLkvlEniU7-FqTeZV4Nhs6pGWu7GGUw4ZqE=.af23b0b6-4425-4d58-9e68-de7d56938a4d@github.com>

On Wed, 28 Sep 2022 17:21:53 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> O_CLOEXEC is also available on macOS (__DARWIN_C_LEVEL >= 200809L), so use it same as on linux.
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add test to verify that open(O_CLOEXEC) implies FD_CLOEXEC on macOS
>  - assume O_CLOEXEC on macOS

test/hotspot/gtest/runtime/test_os.cpp line 892:

> 890: 
> 891: TEST_VM(os, open_O_CLOEXEC) {
> 892: #if defined(__APPLE__)

Does this not work on other OS ie Linux?

-------------

PR: https://git.openjdk.org/jdk/pull/9663

From sgehwolf at openjdk.org  Thu Sep 29 09:35:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Sep 2022 09:35:39 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v4]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <AEyJcJcRM1Jl7Q87iSTMtFCbhW_rimqnjBA6wJHvMPs=.8caa82b5-8ae2-4bcb-96c4-98205c016e08@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [x] GHA all pass.
> 
> Please review! Many thanks in advance.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Add comments/@bug in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10248/files
  - new: https://git.openjdk.org/jdk/pull/10248/files/8059dd81..6061a475

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02-03

  Stats: 6 lines in 4 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

PR: https://git.openjdk.org/jdk/pull/10248

From sgehwolf at openjdk.org  Thu Sep 29 09:35:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Sep 2022 09:35:39 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <TJY2GKBQMw6V9Fi1LgT2hnyOdaiziTeHNAz7_NR2Zo8=.bc9e32d9-1d33-436e-b5fd-1658c6f319d1@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
 <TJY2GKBQMw6V9Fi1LgT2hnyOdaiziTeHNAz7_NR2Zo8=.bc9e32d9-1d33-436e-b5fd-1658c6f319d1@github.com>
Message-ID: <85W4uWEoa4BGsXK82_8x1y16cg3pPpDf5QO-2l5tp6Q=.023d9525-e803-434a-b831-a4d3b5bb7617@github.com>

On Wed, 28 Sep 2022 05:45:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts
>
> The JDK change looks good to me. Some nits for the test cases.

Thanks for the review @iklam!

> test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @summary Verify that -XshowSettings:system works
> 
> Add `@bug 8293540`

Thanks, added.

> test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64:
> 
>> 62:         opts.addDockerOpts("--memory", "300m");
>> 63:         if (addCgroupMounts) {
>> 64:             opts.addDockerOpts("--volume", "/sys/fs/cgroup:/cgroup-in:ro");
> 
> Add comments that the extra mount should be ignored by the cgroup set-up code. (Same for other test cases).

OK. Added in the updated version.

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From sgehwolf at openjdk.org  Thu Sep 29 12:11:25 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Sep 2022 12:11:25 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v5]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <Y70XMKVNdGDJMcibQh-3JXWzJHKT7Q151u8fbbRD1os=.1df935a7-3fe8-4683-bac1-4028951b5ed5@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [x] GHA all pass.
> 
> Please review! Many thanks in advance.

Severin Gehwolf 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-8293540-metrics-cgroups-mounts
 - Add comments/@bug in tests
 - 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10248/files
  - new: https://git.openjdk.org/jdk/pull/10248/files/6061a475..3ecb3b9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03-04

  Stats: 30991 lines in 1069 files changed: 14803 ins; 10731 del; 5457 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

PR: https://git.openjdk.org/jdk/pull/10248

From alanb at openjdk.org  Thu Sep 29 13:03:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Sep 2022 13:03:18 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <ROx1SvAhfFAXAGAtWdclGPHUzY1h-zDKqYtQCT7ZC28=.15be99ab-1ea3-43b8-99d9-c1315a858b11@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

I think I agree with David that the JBS issue or PR needs a better description of the issue. It reads to me that this is caused by setting LD_LIBRARY_PATH to find a libjvm that is coming from somewhere else, is that right?

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From gziemski at openjdk.org  Thu Sep 29 14:43:27 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 29 Sep 2022 14:43:27 GMT
Subject: RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC
 [v2]
In-Reply-To: <G37nhOSFoLkvlEniU7-FqTeZV4Nhs6pGWu7GGUw4ZqE=.af23b0b6-4425-4d58-9e68-de7d56938a4d@github.com>
References: <OMTgeozYd-QlvJa95RoDIo1hvCQQA8rbb-cMO7lGGyw=.e47f12df-cb5d-4c0a-99c8-412f5993d8e4@github.com>
 <5rmdnfrygi8Fmz9OBA8Bd1OebPJSgVKG1G4SyuapMwY=.54415438-2a31-4645-8899-06eace1a1ef1@github.com>
 <G37nhOSFoLkvlEniU7-FqTeZV4Nhs6pGWu7GGUw4ZqE=.af23b0b6-4425-4d58-9e68-de7d56938a4d@github.com>
Message-ID: <CKZVHu0fzKfT_mz1kSwWtym8jgUsBYcA76vai7n8abs=.53162981-93cb-420d-adf6-6ce4e9e712cc@github.com>

On Thu, 29 Sep 2022 07:47:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add test to verify that open(O_CLOEXEC) implies FD_CLOEXEC on macOS
>>  - assume O_CLOEXEC on macOS
>
> test/hotspot/gtest/runtime/test_os.cpp line 892:
> 
>> 890: 
>> 891: TEST_VM(os, open_O_CLOEXEC) {
>> 892: #if defined(__APPLE__)
> 
> Does this not work on other OS ie Linux?

It works on Linux too and originally I had it for both Mac and Linux, but I figured that since this issue (dropping `FD_CLOEXEC` and relaying on only `O_CLOEXEC`) is focused just on MacOS, then that's the platform we should test.

I can add Linux here though, if you think it would be useful.

-------------

PR: https://git.openjdk.org/jdk/pull/9663

From pchilanomate at openjdk.org  Thu Sep 29 15:38:49 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 29 Sep 2022 15:38:49 GMT
Subject: Integrated: 8294370: Fix allocation bug in
 java_lang_Thread::async_get_stack_trace()
In-Reply-To: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
References: <tJ90QgfX6BDi1Be5tLYC_SizsrHFFbbExz6-ub9soPU=.151312a9-fae0-4738-a620-a4869a800880@github.com>
Message-ID: <8SL4dWPsOCNogjLSsa0QFR9mh-n3n5TVbriMfmtXU1E=.616f0158-50f5-427d-927d-4577ef9a8251@github.com>

On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description).
> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests.
> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with.
> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 5d48da45
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d48da4574f6aacb0db445dd5750566330aa383d
Stats:     11 lines in 1 file changed: 6 ins; 0 del; 5 mod

8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace()

Reviewed-by: dholmes, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/10424

From shade at openjdk.org  Thu Sep 29 16:22:09 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Sep 2022 16:22:09 GMT
Subject: RFR: 8294594: Fix cast-function-type warning in signal handling code
Message-ID: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>

After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10494/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294594
  Stats: 8 lines in 3 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10494/head:pull/10494

PR: https://git.openjdk.org/jdk/pull/10494

From coleenp at openjdk.org  Thu Sep 29 19:30:24 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Sep 2022 19:30:24 GMT
Subject: RFR: 8293969: breakup the long signature in
 SystemDictionaryShared::is_supported_invokedynamic
In-Reply-To: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>
References: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>
Message-ID: <IuSiCNnUjkOtqr_QMiiHS2Z4sCs62PXICDrGFRFSgXo=.b379f258-a2ab-407c-9379-4e8af1e75f51@github.com>

On Tue, 27 Sep 2022 15:44:30 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Broke up signature into three lines. Tested with tier 1. Please review

Looks good.  Trivial, can be pushed today!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10452

From duke at openjdk.org  Thu Sep 29 20:20:10 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Thu, 29 Sep 2022 20:20:10 GMT
Subject: Integrated: 8293969: breakup the long signature in
 SystemDictionaryShared::is_supported_invokedynamic
In-Reply-To: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>
References: <Pa8YTCJrZvzUBkzjbHKw0Xbw4UnNtwpP3l6W9zuh6UA=.df511230-4946-4225-8d43-0c5bb0a446be@github.com>
Message-ID: <3H3FpBhSFYAGOpMfkCjwjLF_ThBqeNUDCxUGeONogSo=.25589fef-4ac9-45ee-a19e-7295c9e6796c@github.com>

On Tue, 27 Sep 2022 15:44:30 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Broke up signature into three lines. Tested with tier 1. Please review

This pull request has now been integrated.

Changeset: 88062eea
Author:    Matias Saavedra Silva <matias.s.saavedra.silva at oracle.com>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88062eea67e6c9f30be5dfa53016b8643f12d4b8
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8293969: breakup the long signature in SystemDictionaryShared::is_supported_invokedynamic

Reviewed-by: eastigeevich, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/10452

From darcy at openjdk.org  Fri Sep 30 01:37:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:37:10 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <inJGt-dp4UAY7vyr36iG9TCPyoAtieU4qd4czgxIu90=.c506a0a8-1ad3-4a29-adca-9e5ccae56025@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Years back, I worked on maintaining the launcher. Previously the launcher could re-exec to change data model (e.g. change from 32 to 64 bit on a Solaris environment that supported both options) and to pick a different version.

IIRC, both features were dropped so I would also need some additional context and explanation as it what is being attempted here.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From lmesnik at openjdk.org  Fri Sep 30 01:41:42 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Sep 2022 01:41:42 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed:
 JVMTI_ERROR_WRONG_PHASE
Message-ID: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>

8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

-------------

Commit messages:
 - 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

Changes: https://git.openjdk.org/jdk/pull/10502/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294406
  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10502/head:pull/10502

PR: https://git.openjdk.org/jdk/pull/10502

From dholmes at openjdk.org  Fri Sep 30 04:40:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Sep 2022 04:40:24 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <UPnMTjF5NM8b_FB5520oboNni3tvTO90XwOmOjsOqOk=.f43279e3-e414-488d-9044-336bf422c12e@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

Why is `JVMTI_ERROR_WRONG_PHASE` a valid result here?

-------------

PR: https://git.openjdk.org/jdk/pull/10502

From dholmes at openjdk.org  Fri Sep 30 04:56:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Sep 2022 04:56:33 GMT
Subject: RFR: 8294594: Fix cast-function-type warning in signal handling
 code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

Marked as reviewed by dholmes (Reviewer).

src/hotspot/os/posix/signals_posix.cpp line 1727:

> 1725:   // Set up signal handler for suspend/resume
> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);

The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10494

From sspitsyn at openjdk.org  Fri Sep 30 06:26:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Sep 2022 06:26:26 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <UPnMTjF5NM8b_FB5520oboNni3tvTO90XwOmOjsOqOk=.f43279e3-e414-488d-9044-336bf422c12e@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
 <UPnMTjF5NM8b_FB5520oboNni3tvTO90XwOmOjsOqOk=.f43279e3-e414-488d-9044-336bf422c12e@github.com>
Message-ID: <HdtyMS_kKt5b-LFGLpx-u2y8ctTT3Ee453agi25d6K0=.366714d6-b120-4a38-8da8-4121d83fb1c9@github.com>

On Fri, 30 Sep 2022 04:37:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why is `JVMTI_ERROR_WRONG_PHASE` a valid result here?

I think, it is because the testing `suspendResumeThread` tread is a daemon thread.
I'm not sure why it was set to be a daemon thread though.

-------------

PR: https://git.openjdk.org/jdk/pull/10502

From dzhang at openjdk.org  Fri Sep 30 08:44:25 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 30 Sep 2022 08:44:25 GMT
Subject: RFR: JDK-8294623: gtest does not work with googletest release-1.12.0+
Message-ID: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>

The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:


$ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"

* For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
                 from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
                 from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
                 from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
                 from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
                 from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:

-------------

Commit messages:
 - gtest does not work with googletest release-1.12.0+

Changes: https://git.openjdk.org/jdk/pull/10503/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294623
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10503.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10503/head:pull/10503

PR: https://git.openjdk.org/jdk/pull/10503

From sgehwolf at openjdk.org  Fri Sep 30 08:48:35 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Sep 2022 08:48:35 GMT
Subject: Integrated: 8293540: [Metrics] Incorrectly detected resource limits
 with additional cgroup fs mounts
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <A3aAd8Bk52jpvZ96RQcr3C1gUuSbNnI16NXYvIvURVg=.9f78f1d7-47ef-4ecd-a5bb-11817792e84f@github.com>

On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [x] GHA all pass.
> 
> Please review! Many thanks in advance.

This pull request has now been integrated.

Changeset: 6d83482a
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d83482a6b5f1898514fd450d8143dbfef57e362
Stats:     181 lines in 6 files changed: 143 ins; 23 del; 15 mod

8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts

Reviewed-by: iklam

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From dsamersoff at openjdk.org  Fri Sep 30 12:56:20 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Fri, 30 Sep 2022 12:56:20 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <Ngug_uJlyTYFE1p3EtyaLpDOYRtQvcl2AkZxLGbqBqA=.e00ef1cd-cb3c-442a-8a07-d9839dcdfcfd@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

_I updated description in the CR, https://bugs.openjdk.org/browse/JDK-8293806 but for convenience copy it here. Also, I added some debug output to the comments for CR_

Under some circumstances, the launcher have to update LD_LIBRARY_PATH, but the runtime linker only considers this variable during application startup, so after updating LD_LIBRARY_PATH the launcher must re-execute it self by calling execvp().

The decision to re-launch is made after all options from all sources (JDK_JAVA_OPTIONS, @argfile) already been processed and copied to argv[] array. Thus, parameters passed through JDK_JAVA_OPTIONS variable are processed twice.

If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.

We cannot just remove the JDK_JAVA_OPTIONS variable because some applications (e.g. IDEs) use it to pass user parameters through the chain of child java processes.

It happens under following conditions:

1. Under MUSL libc launcher have to set LD_LIBRARY_PATH to resolve dependency between libjava and libjvm
2. On AIX launcher have to set LD_LIBRARY_PATH because the runtime linker doesn't support $ORIGIN
3. User set LD_LIBRARY_PATH variable to some location containing libjvm.so. According to comment in java_md.c, LD_LIBRARY_PATH have to be updated to avoid recursion.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From rehn at openjdk.org  Fri Sep 30 13:09:30 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 30 Sep 2022 13:09:30 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <Nku-2pgnI5w_00WIa9tT6jE-o4ow1j_Axc-XPnxbccs=.19f9d85e-1d5a-4301-99c6-8c9e1aad37b3@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

The reason for it to be a daemon is that this thread should try to suspend/resume when we are terminating, thus trying to hit those rare exit parts where we do thread exits with a pending suspend.

-------------

PR: https://git.openjdk.org/jdk/pull/10502

From fyang at openjdk.org  Fri Sep 30 14:48:01 2022
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 30 Sep 2022 14:48:01 GMT
Subject: RFR: 8294679: RISC-V: Misc crash dump improvements
Message-ID: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>

Issue https://bugs.openjdk.org/browse/JDK-8294160 only handles x86 & aarch64.
This adds handling for this case on RISC-V: When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.

Testing: Tier1 tested on HiFive Unmatched board.

-------------

Commit messages:
 - 8294679: RISC-V: Misc crash dump improvements

Changes: https://git.openjdk.org/jdk/pull/10512/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10512&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294679
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10512.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10512/head:pull/10512

PR: https://git.openjdk.org/jdk/pull/10512

From sspitsyn at openjdk.org  Fri Sep 30 20:27:52 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Sep 2022 20:27:52 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <4ZvQD6hkKP6tdNx_7xYJYgZhTwJJmVCHlpOc6_IhRUc=.65052a1f-565b-48f2-8208-ce0a4bba4f09@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

The fix looks good.
Thanks,
Serguei

Thanks, Robbin. I see the point.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10502