From xliu at openjdk.java.net  Tue Jun  1 00:26:21 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 1 Jun 2021 00:26:21 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
Message-ID: <f94AWRZe7Snk1Kfsj5lnoNU876KbuU42CRm0jqFcjQQ=.f9db1848-f385-402b-bb8a-19cdddedea76@github.com>

On Mon, 31 May 2021 22:14:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase reader's counter before creating LogDecoration.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 105:
> 
>> 103: 
>> 104:     if (*counter > 0) {
>> 105:       LogDecorations decorations(LogLevel::Warning, none::tagset(), LogDecorators::All);
> 
> This looks odd to use LogDecorators::All - what exactly will that produce?

This is the out-of-band message, it just shows that "xyz messages dropped due to async logging." 

Unlike normal log messages, this ad-hoc message is enqueued when buffer is flushing. The synchronization I described in `LogConfiguration::configure_output` only protects enqueuing log messages.  This message is not under protection.Without LogDecorators::All, it will fail 'gtest:LogConfigurationTest.reconfigure_decorators_MT*' in async log mode.

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

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

From iklam at openjdk.java.net  Tue Jun  1 01:10:28 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Jun 2021 01:10:28 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v2]
In-Reply-To: <ahD_Pw1J-IevEp776izq4wDNu17-Chgh0TOGMDnXzVc=.f2eba523-dca3-446d-8c63-7442e0d96e4e@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com>
 <ahD_Pw1J-IevEp776izq4wDNu17-Chgh0TOGMDnXzVc=.f2eba523-dca3-446d-8c63-7442e0d96e4e@github.com>
Message-ID: <stgr7jGmYoAutiAW_vZoJWjKlbmUB6e3d84rxZ14ACY=.e1493b2d-8f08-4ad2-b9c7-d2323771bab1@github.com>

On Mon, 31 May 2021 22:32:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8267118-oome
>>  - 8267118: OutOfMemoryError cannot be caught as a Throwable
>
> src/hotspot/share/oops/method.cpp line 232:
> 
>> 230:   if (do_logging) {
>> 231:     ResourceMark rm(THREAD);
>> 232:     log_info(exceptions)("Looking for catch handler for exception of type \"%s\" in method \"%s\"",
> 
> I think these should be log_debug, since this is useful for debugging but many people outside of hotspot engineers use -Xlog:exceptions.

If the exception is not immediately caught, will this print a line for every method on the call stack that has a catch block? If so, that may be too verbose.

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

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

From david.holmes at oracle.com  Tue Jun  1 01:25:48 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Jun 2021 11:25:48 +1000
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v2]
In-Reply-To: <stgr7jGmYoAutiAW_vZoJWjKlbmUB6e3d84rxZ14ACY=.e1493b2d-8f08-4ad2-b9c7-d2323771bab1@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com>
 <ahD_Pw1J-IevEp776izq4wDNu17-Chgh0TOGMDnXzVc=.f2eba523-dca3-446d-8c63-7442e0d96e4e@github.com>
 <stgr7jGmYoAutiAW_vZoJWjKlbmUB6e3d84rxZ14ACY=.e1493b2d-8f08-4ad2-b9c7-d2323771bab1@github.com>
Message-ID: <954d782a-82e3-ba61-1b53-3e00850645a5@oracle.com>

Hi Ioi,

Thanks for looking at this.

On 1/06/2021 11:10 am, Ioi Lam wrote:
> On Mon, 31 May 2021 22:32:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>>>
>>>   - Merge branch 'master' into 8267118-oome
>>>   - 8267118: OutOfMemoryError cannot be caught as a Throwable
>>
>> src/hotspot/share/oops/method.cpp line 232:
>>
>>> 230:   if (do_logging) {
>>> 231:     ResourceMark rm(THREAD);
>>> 232:     log_info(exceptions)("Looking for catch handler for exception of type \"%s\" in method \"%s\"",
>>
>> I think these should be log_debug, since this is useful for debugging but many people outside of hotspot engineers use -Xlog:exceptions.
> 
> If the exception is not immediately caught, will this print a line for every method on the call stack that has a catch block? If so, that may be too verbose.

Yes it will. Okay I see your point.

The main reason people turn on exception logging is because an exception 
has been swallowed somewhere and they need to find where. So I'd want to 
show where the exception is caught at Info level to match the throw at 
Info level. The rest can be debug but now I'll have to put more 
information in the Info message.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4266
> 

From david.holmes at oracle.com  Tue Jun  1 01:27:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Jun 2021 11:27:58 +1000
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <f94AWRZe7Snk1Kfsj5lnoNU876KbuU42CRm0jqFcjQQ=.f9db1848-f385-402b-bb8a-19cdddedea76@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
 <f94AWRZe7Snk1Kfsj5lnoNU876KbuU42CRm0jqFcjQQ=.f9db1848-f385-402b-bb8a-19cdddedea76@github.com>
Message-ID: <a4c890a1-a385-f875-3ca4-cfd7ee53c9d8@oracle.com>

On 1/06/2021 10:26 am, Xin Liu wrote:
> On Mon, 31 May 2021 22:14:46 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Increase reader's counter before creating LogDecoration.
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 105:
>>
>>> 103:
>>> 104:     if (*counter > 0) {
>>> 105:       LogDecorations decorations(LogLevel::Warning, none::tagset(), LogDecorators::All);
>>
>> This looks odd to use LogDecorators::All - what exactly will that produce?
> 
> This is the out-of-band message, it just shows that "xyz messages dropped due to async logging."
> 
> Unlike normal log messages, this ad-hoc message is enqueued when buffer is flushing. The synchronization I described in `LogConfiguration::configure_output` only protects enqueuing log messages.  This message is not under protection.Without LogDecorators::All, it will fail 'gtest:LogConfigurationTest.reconfigure_decorators_MT*' in async log mode.

I understand the need to not use the true decorators, but using All 
sounds like it will produce a log line with an excessive number of 
decorators applied:

Available log decorators:
  time (t), utctime (utc), uptime (u), timemillis (tm), uptimemillis 
(um), timenanos (tn), uptimenanos (un), hostname (hn), pid (p), tid 
(ti), level (l), tags (tg)

will all of those appear on this log line?

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4257
> 

From dholmes at openjdk.java.net  Tue Jun  1 02:41:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 02:41:43 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
Message-ID: <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>

> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
> 
> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
> 
> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
> 
> Testing: tiers 1-3, plus the new test
> 
> Thanks,
> David

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

  Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
  feedback from @coleenp @iklam

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4266/files
  - new: https://git.openjdk.java.net/jdk/pull/4266/files/f5718224..57561f1d

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

  Stats: 34 lines in 1 file changed: 20 ins; 1 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4266/head:pull/4266

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

From david.holmes at oracle.com  Tue Jun  1 02:46:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Jun 2021 12:46:36 +1000
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
Message-ID: <a35a8319-b7f6-e272-8cc7-a46fec6523d5@oracle.com>

On 1/06/2021 12:41 pm, David Holmes wrote:
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>    feedback from @coleenp @iklam

Added example program and output to the bug report.

David
> 
> PR: https://git.openjdk.java.net/jdk/pull/4266
> 

From xxinliu at amazon.com  Tue Jun  1 03:49:14 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Mon, 31 May 2021 20:49:14 -0700
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <a4c890a1-a385-f875-3ca4-cfd7ee53c9d8@oracle.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
 <f94AWRZe7Snk1Kfsj5lnoNU876KbuU42CRm0jqFcjQQ=.f9db1848-f385-402b-bb8a-19cdddedea76@github.com>
 <a4c890a1-a385-f875-3ca4-cfd7ee53c9d8@oracle.com>
Message-ID: <c56b9c6c-77fd-3318-81cb-1a545acd20b8@amazon.com>

Hi, David,

No, logoutput won't show all decorators. It just materialize
logDecorations for All. This only happens when lost logs happen.

It's very tricky here, but it's essential to reason how the lockless
synchronization works for LogDecorations in
LogConfiguration::configure_output.

A LogDecorators a SET of decorators in bitmask. A LogDecorations
instance represents a materialized LogDecorators.

There are 2 different LogDecorations instances coexist.?
Set 1: LogOutput::_decorators, which is used to select which decorations
are output. LogFileStreamOutput::write_decorations()
Set 2: LogTagSet::_decorators, which is used to materialize LogDecorations.


In any give time, set 1 is a 'subset' of set 2. This guarantees that
write_decorations() always outputs defined decorations.

Why configure_output() is MT-safe if users allow to change decorations
dynamically? Let's say the new decorations user provided is set N.

There are 4 steps in configure_output().
1) ts->update_decorators(decorators);   // set 2 = union(set 2, set N)
2) ts->set_output_level(output, level); // wait_until_no_readers()
After it, ts->log() must see the new set 2 in synchronous logging.
Some async log message with old decorations may be in the buffer. This
is the Hazard #1.
3) output->set_decorators(decorators);  // set 1 = set N in atomic.
4) ts->update_decorators(LogDecorators::None); // set 2 = intersect(set
2, set N), essentially shrink the set 2 to set N.

This mechanism is intrigue. That's why I try to comment it out. I also
discover a race condition which only happens in preemptive context
switch. Please help me to review the change in LogTagSet::log().

To make current mechanism support async logging, I insert a
AsyncLogWriter::flush() before step 3).  Yes, after flush() returns,
logsites can still enqueues messages in parallel, but they must seen new
set 2! It's not hazard.


thanks,
--lx



On 5/31/21 6:27 PM, David Holmes wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 1/06/2021 10:26 am, Xin Liu wrote:
>> On Mon, 31 May 2021 22:14:46 GMT, David Holmes <dholmes at openjdk.org> wrote:
>>
>>>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>>>
>>>>    Increase reader's counter before creating LogDecoration.
>>>
>>> src/hotspot/share/logging/logAsyncWriter.cpp line 105:
>>>
>>>> 103:
>>>> 104:     if (*counter > 0) {
>>>> 105:       LogDecorations decorations(LogLevel::Warning, none::tagset(), LogDecorators::All);
>>>
>>> This looks odd to use LogDecorators::All - what exactly will that produce?
>>
>> This is the out-of-band message, it just shows that "xyz messages dropped due to async logging."
>>
>> Unlike normal log messages, this ad-hoc message is enqueued when buffer is flushing. The synchronization I described in `LogConfiguration::configure_output` only protects enqueuing log messages.  This message is not under protection.Without LogDecorators::All, it will fail 'gtest:LogConfigurationTest.reconfigure_decorators_MT*' in async log mode.
> 
> I understand the need to not use the true decorators, but using All
> sounds like it will produce a log line with an excessive number of
> decorators applied:
> 
> Available log decorators:
>   time (t), utctime (utc), uptime (u), timemillis (tm), uptimemillis
> (um), timenanos (tn), uptimenanos (un), hostname (hn), pid (p), tid
> (ti), level (l), tags (tg)
> 
> will all of those appear on this log line?
> 
> Thanks,
> David
> 
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4257
>>

From xliu at openjdk.java.net  Tue Jun  1 04:09:10 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 1 Jun 2021 04:09:10 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
Message-ID: <S4-QOcb5TCPiMXGQ3ypu77ZqWzt9Alt29OgNNLHIy7o=.02303cd4-b0c1-4a37-9c47-671758db0027@github.com>

On Mon, 31 May 2021 22:22:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase reader's counter before creating LogDecoration.
>
> src/hotspot/share/logging/logConfiguration.cpp line 279:
> 
>> 277:   //
>> 278:   AsyncLogWriter::flush();
>> 279: 
> 
> As soon as this completes, new logging requests could have been enqueued, thus restoring the hazard.

This is not true. Yes, new logsites could have been enqueued, but they must see the new tags and the new decorations. please note `ts->set_output_level(output, level)` implies a  wait_until_no_readers() if anything does change. 

One trick is I treat asynclog enqueuing as same as synclog writing. `wait_until_no_readers` also takes effect for async logging. It guarantees that all enqueuing async logs are done before the reader counter reset back to 0. If there're ongoing log requests with old tags or decorations, they all have enqueued before `wait_until_no_readers()` returns.  that's why one flush() is enough for the two hazards.

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

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

From dholmes at openjdk.java.net  Tue Jun  1 05:12:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 05:12:28 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
Message-ID: <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>

On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>> 
>> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
>> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
>> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase reader's counter before creating LogDecoration.

I put the latest patch through our tier 1-4 testing and it crashed in tier 3 on Linux-Aarch64:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# C  [libc.so.6+0x60720]  flockfile+0x0
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/a4f8fba9-f017-4328-b286-c66b6a97143d-S808/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/42993029-a18a-48c4-9a4d-108aee7b3811/runs/a38508fe-5d43-48ad-b70a-61f3e712fcd8/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.3972473)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -XX:+ExecutingUnitTests -Xlog:async 

Host: AArch64, 6 cores, 46G, Oracle Linux Server release 8.3
Time: Mon May 31 22:37:04 2021 UTC elapsed time: 3.758723 seconds (0d 0h 0m 3s)

---------------  T H R E A D  ---------------

Current thread (0x0000aaadf32b1e10):  Thread "AsyncLog Thread" [stack: 0x0000fffefdaa0000,0x0000fffefdca0000] [id=3972481]

Stack: [0x0000fffefdaa0000,0x0000fffefdca0000],  sp=0x0000fffefdc9e510,  free space=2041k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x60720]  flockfile+0x0
V  [libjvm.so+0x1508058]  LogFileOutput::write_blocking(LogDecorations const&, char const*)+0x38
V  [libjvm.so+0x1502764]  AsyncLogWriter::run()+0x2c0
V  [libjvm.so+0x1a49d08]  Thread::call_run()+0xf8
V  [libjvm.so+0x1766f18]  thread_native_entry(Thread*)+0x108
C  [libpthread.so.0+0x76e0]  start_thread+0x198

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

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

From navy.xliu at gmail.com  Tue Jun  1 05:48:38 2021
From: navy.xliu at gmail.com (Liu Xin)
Date: Mon, 31 May 2021 22:48:38 -0700
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>
Message-ID: <CAHPdc0=vuY0Sj-7oArh_YTr7K3ktWR3_yKHUukwYSjeLXgZ=Jg@mail.gmail.com>

hi, David,

This is awkward. I think I changed too many in a patch.

Do you think it is a good idea that I revert to
https://openjdk.github.io/cr/?repo=jdk&pr=4257&range=00
It is a trivial bugfix.  Does it solve tier1~4 on aarch64?

If it does, we can know that this new crash is caused by the change in my
new patch.
I would recall it and rework it on aarch64.

It seems that it crashed while executing gtest in async mode.   Could you
tell me which gtest it was executing?
"Command Line: -XX:+ExecutingUnitTests -Xlog:async"

thanks,
--lx


On Mon, May 31, 2021 at 10:13 PM David Holmes <dholmes at openjdk.java.net>
wrote:

> On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org> wrote:
>
> >> The root cause of the intermittent failure is that _decorators in
> LogDecorations
> >> may be inconsistent with LogOutput::_decorators. It could happen when
> gtest disables a
> >> Log output via set_log_config(TestLogFileName, "all=off").
> >>
> >> Since we copy the entire logDecorations, it's reasonable to copy
> _decorator as well.
> >> LogDecorator is a bitmask of uint. It's even smaller than a reference
> on LP64 platforms.
> >>
> >> This patch not only fixes intermittent crash in JDK-8267926, but also
> fixes JDK-8267952.
> >> Two hazards of async logging in `LogConfiguration::configure_output`
> are eliminated.
> >> This patch also adds a storestore barrier to make sure it's safe on
> weak consistency machines.
> >
> > Xin Liu has updated the pull request incrementally with one additional
> commit since the last revision:
> >
> >   Increase reader's counter before creating LogDecoration.
>
> I put the latest patch through our tier 1-4 testing and it crashed in tier
> 3 on Linux-Aarch64:
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481
> #
> # JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build
> 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug
> 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git, mixed mode,
> tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # C  [libc.so.6+0x60720]  flockfile+0x0
> #
> # Core dump will be written. Default location: Core dumps may be processed
> with "/opt/core.sh %p" (or dumping to
> /opt/mach5/mesos/work_dir/slaves/a4f8fba9-f017-4328-b286-c66b6a97143d-S808/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/42993029-a18a-48c4-9a4d-108aee7b3811/runs/a38508fe-5d43-48ad-b70a-61f3e712fcd8/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.3972473)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
>
> ---------------  S U M M A R Y ------------
>
> Command Line: -XX:+ExecutingUnitTests -Xlog:async
>
> Host: AArch64, 6 cores, 46G, Oracle Linux Server release 8.3
> Time: Mon May 31 22:37:04 2021 UTC elapsed time: 3.758723 seconds (0d 0h
> 0m 3s)
>
> ---------------  T H R E A D  ---------------
>
> Current thread (0x0000aaadf32b1e10):  Thread "AsyncLog Thread" [stack:
> 0x0000fffefdaa0000,0x0000fffefdca0000] [id=3972481]
>
> Stack: [0x0000fffefdaa0000,0x0000fffefdca0000],  sp=0x0000fffefdc9e510,
> free space=2041k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C  [libc.so.6+0x60720]  flockfile+0x0
> V  [libjvm.so+0x1508058]  LogFileOutput::write_blocking(LogDecorations
> const&, char const*)+0x38
> V  [libjvm.so+0x1502764]  AsyncLogWriter::run()+0x2c0
> V  [libjvm.so+0x1a49d08]  Thread::call_run()+0xf8
> V  [libjvm.so+0x1766f18]  thread_native_entry(Thread*)+0x108
> C  [libpthread.so.0+0x76e0]  start_thread+0x198
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4257
>

From david.holmes at oracle.com  Tue Jun  1 06:00:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Jun 2021 16:00:03 +1000
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <CAHPdc0=vuY0Sj-7oArh_YTr7K3ktWR3_yKHUukwYSjeLXgZ=Jg@mail.gmail.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>
 <CAHPdc0=vuY0Sj-7oArh_YTr7K3ktWR3_yKHUukwYSjeLXgZ=Jg@mail.gmail.com>
Message-ID: <fdfc039b-5c58-20e1-3f67-72198ef52599@oracle.com>

Hi Xin,

On 1/06/2021 3:48 pm, Liu Xin wrote:
> hi, David,
> 
> This is awkward. I think I changed too many in a patch.
> 
> Do you think it is a good idea that I revert to 
> https://openjdk.github.io/cr/?repo=jdk&pr=4257&range=00 
> <https://openjdk.github.io/cr/?repo=jdk&pr=4257&range=00>
> It is a trivial bugfix.? Does it solve tier1~4 on aarch64?

I didn't test just that patch, but will try to do so.

It might be best to revert to the simple workaround for now to fix the 
test - otherwise I need to get the test problem-listed.

> If it does, we can know that this new crash is caused by the change in 
> my new patch.
> I would recall it and rework it on aarch64.
> 
> It seems that it crashed while executing gtest in async mode.?? Could 
> you tell me which gtest it was executing?
> "Command Line: -XX:+ExecutingUnitTests -Xlog:async"

[ RUN      ] LogConfigurationTest.parse_log_arguments_vm
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481

HTH,
David

> thanks,
> --lx
> 
> 
> On Mon, May 31, 2021 at 10:13 PM David Holmes <dholmes at openjdk.java.net 
> <mailto:dholmes at openjdk.java.net>> wrote:
> 
>     On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org
>     <mailto:xliu at openjdk.org>> wrote:
> 
>      >> The root cause of the intermittent failure is that _decorators
>     in LogDecorations
>      >> may be inconsistent with LogOutput::_decorators. It could happen
>     when gtest disables a
>      >> Log output via set_log_config(TestLogFileName, "all=off").
>      >>
>      >> Since we copy the entire logDecorations, it's reasonable to copy
>     _decorator as well.
>      >> LogDecorator is a bitmask of uint. It's even smaller than a
>     reference on LP64 platforms.
>      >>
>      >> This patch not only fixes intermittent crash in JDK-8267926, but
>     also fixes JDK-8267952.
>      >> Two hazards of async logging in
>     `LogConfiguration::configure_output` are eliminated.
>      >> This patch also adds a storestore barrier to make sure it's safe
>     on weak consistency machines.
>      >
>      > Xin Liu has updated the pull request incrementally with one
>     additional commit since the last revision:
>      >
>      >? ?Increase reader's counter before creating LogDecoration.
> 
>     I put the latest patch through our tier 1-4 testing and it crashed
>     in tier 3 on Linux-Aarch64:
> 
>     #
>     # A fatal error has been detected by the Java Runtime Environment:
>     #
>     #? SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481
>     #
>     # JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug
>     build 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git)
>     # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug
>     17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git,
>     mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc,
>     linux-aarch64)
>     # Problematic frame:
>     # C? [libc.so.6+0x60720]? flockfile+0x0
>     #
>     # Core dump will be written. Default location: Core dumps may be
>     processed with "/opt/core.sh %p" (or dumping to
>     /opt/mach5/mesos/work_dir/slaves/a4f8fba9-f017-4328-b286-c66b6a97143d-S808/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/42993029-a18a-48c4-9a4d-108aee7b3811/runs/a38508fe-5d43-48ad-b70a-61f3e712fcd8/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.3972473)
>     #
>     # If you would like to submit a bug report, please visit:
>     # https://bugreport.java.com/bugreport/crash.jsp
>     <https://bugreport.java.com/bugreport/crash.jsp>
>     #
> 
>     ---------------? S U M M A R Y ------------
> 
>     Command Line: -XX:+ExecutingUnitTests -Xlog:async
> 
>     Host: AArch64, 6 cores, 46G, Oracle Linux Server release 8.3
>     Time: Mon May 31 22:37:04 2021 UTC elapsed time: 3.758723 seconds
>     (0d 0h 0m 3s)
> 
>     ---------------? T H R E A D? ---------------
> 
>     Current thread (0x0000aaadf32b1e10):? Thread "AsyncLog Thread"
>     [stack: 0x0000fffefdaa0000,0x0000fffefdca0000] [id=3972481]
> 
>     Stack: [0x0000fffefdaa0000,0x0000fffefdca0000], 
>     sp=0x0000fffefdc9e510,? free space=2041k
>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>     C=native code)
>     C? [libc.so.6+0x60720]? flockfile+0x0
>     V? [libjvm.so+0x1508058] 
>     LogFileOutput::write_blocking(LogDecorations const&, char const*)+0x38
>     V? [libjvm.so+0x1502764]? AsyncLogWriter::run()+0x2c0
>     V? [libjvm.so+0x1a49d08]? Thread::call_run()+0xf8
>     V? [libjvm.so+0x1766f18]? thread_native_entry(Thread*)+0x108
>     C? [libpthread.so.0+0x76e0]? start_thread+0x198
> 
>     -------------
> 
>     PR: https://git.openjdk.java.net/jdk/pull/4257
>     <https://git.openjdk.java.net/jdk/pull/4257>
> 

From iklam at openjdk.java.net  Tue Jun  1 06:18:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Jun 2021 06:18:23 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
Message-ID: <rI9LJVLmU1U0hj2E6VWcilI3vxp-SkARJxJTnsetXxU=.0ae23fdc-42e3-42a9-adff-f6c7dcc09109@github.com>

On Tue, 1 Jun 2021 02:41:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>> 
>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>> 
>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>> 
>> Testing: tiers 1-3, plus the new test
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>   feedback from @coleenp @iklam

LGTM

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

Marked as reviewed by iklam (Reviewer).

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

From jiefu at openjdk.java.net  Tue Jun  1 08:18:26 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 08:18:26 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
Message-ID: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>

Hi all,

Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).

@dholmes-ora had reminded me of this bug in [1].
But I missed the fact that ZGC is currently only built on x64 and aarch64.
And I'm sorry for this breakage.

The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].

Thanks.
Best regards,
Jie


[1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
[2] https://github.com/numactl/numactl/blob/master/syscall.c

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

Commit messages:
 - 8268014: Build failure on SUSE Linux Enterprise Server 11.4 (s390x) due to 'SYS_get_mempolicy' was not declared

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

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

From dholmes at openjdk.java.net  Tue Jun  1 09:16:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 09:16:19 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <0CEw3OWKeVAEM-I_k5MAg2sO7_2DC0mFmTeXPk42DJc=.29cd43d2-6e57-4491-b090-437930967479@github.com>

On Tue, 1 Jun 2021 08:11:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

Looks fine.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From jiefu at openjdk.java.net  Tue Jun  1 09:25:19 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 09:25:19 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <0CEw3OWKeVAEM-I_k5MAg2sO7_2DC0mFmTeXPk42DJc=.29cd43d2-6e57-4491-b090-437930967479@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <0CEw3OWKeVAEM-I_k5MAg2sO7_2DC0mFmTeXPk42DJc=.29cd43d2-6e57-4491-b090-437930967479@github.com>
Message-ID: <ZY6i3eWE7V786eAT7G92c_pEhgRi37kqyLZvrhm7ENs=.c0cac1fa-6a74-4d80-a91d-7e29fb14a777@github.com>

On Tue, 1 Jun 2021 09:13:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Looks fine.
> 
> Thanks,
> David

Thanks @dholmes-ora .

@Martin Doerr, please let me know if the build failure can be fixed by this change.
Thanks.

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

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

From david.holmes at oracle.com  Tue Jun  1 09:30:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Jun 2021 19:30:43 +1000
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <fdfc039b-5c58-20e1-3f67-72198ef52599@oracle.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>
 <CAHPdc0=vuY0Sj-7oArh_YTr7K3ktWR3_yKHUukwYSjeLXgZ=Jg@mail.gmail.com>
 <fdfc039b-5c58-20e1-3f67-72198ef52599@oracle.com>
Message-ID: <82ecda82-5768-4a70-7c59-5534208a0a63@oracle.com>

On 1/06/2021 4:00 pm, David Holmes wrote:
> Hi Xin,
> 
> On 1/06/2021 3:48 pm, Liu Xin wrote:
>> hi, David,
>>
>> This is awkward. I think I changed too many in a patch.
>>
>> Do you think it is a good idea that I revert to 
>> https://openjdk.github.io/cr/?repo=jdk&pr=4257&range=00 
>> <https://openjdk.github.io/cr/?repo=jdk&pr=4257&range=00>
>> It is a trivial bugfix.? Does it solve tier1~4 on aarch64?
> 
> I didn't test just that patch, but will try to do so.

The basic change passed tiers 1-4 testing.

Thanks,
David
-----

> It might be best to revert to the simple workaround for now to fix the 
> test - otherwise I need to get the test problem-listed.
> 
>> If it does, we can know that this new crash is caused by the change in 
>> my new patch.
>> I would recall it and rework it on aarch64.
>>
>> It seems that it crashed while executing gtest in async mode.?? Could 
>> you tell me which gtest it was executing?
>> "Command Line: -XX:+ExecutingUnitTests -Xlog:async"
> 
> [ RUN????? ] LogConfigurationTest.parse_log_arguments_vm
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #? SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481
> 
> HTH,
> David
> 
>> thanks,
>> --lx
>>
>>
>> On Mon, May 31, 2021 at 10:13 PM David Holmes 
>> <dholmes at openjdk.java.net <mailto:dholmes at openjdk.java.net>> wrote:
>>
>> ??? On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org
>> ??? <mailto:xliu at openjdk.org>> wrote:
>>
>> ???? >> The root cause of the intermittent failure is that _decorators
>> ??? in LogDecorations
>> ???? >> may be inconsistent with LogOutput::_decorators. It could happen
>> ??? when gtest disables a
>> ???? >> Log output via set_log_config(TestLogFileName, "all=off").
>> ???? >>
>> ???? >> Since we copy the entire logDecorations, it's reasonable to copy
>> ??? _decorator as well.
>> ???? >> LogDecorator is a bitmask of uint. It's even smaller than a
>> ??? reference on LP64 platforms.
>> ???? >>
>> ???? >> This patch not only fixes intermittent crash in JDK-8267926, but
>> ??? also fixes JDK-8267952.
>> ???? >> Two hazards of async logging in
>> ??? `LogConfiguration::configure_output` are eliminated.
>> ???? >> This patch also adds a storestore barrier to make sure it's safe
>> ??? on weak consistency machines.
>> ???? >
>> ???? > Xin Liu has updated the pull request incrementally with one
>> ??? additional commit since the last revision:
>> ???? >
>> ???? >? ?Increase reader's counter before creating LogDecoration.
>>
>> ??? I put the latest patch through our tier 1-4 testing and it crashed
>> ??? in tier 3 on Linux-Aarch64:
>>
>> ??? #
>> ??? # A fatal error has been detected by the Java Runtime Environment:
>> ??? #
>> ??? #? SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481
>> ??? #
>> ??? # JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug
>> ??? build 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git)
>> ??? # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug
>> ??? 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git,
>> ??? mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc,
>> ??? linux-aarch64)
>> ??? # Problematic frame:
>> ??? # C? [libc.so.6+0x60720]? flockfile+0x0
>> ??? #
>> ??? # Core dump will be written. Default location: Core dumps may be
>> ??? processed with "/opt/core.sh %p" (or dumping to
>>     
>> /opt/mach5/mesos/work_dir/slaves/a4f8fba9-f017-4328-b286-c66b6a97143d-S808/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/42993029-a18a-48c4-9a4d-108aee7b3811/runs/a38508fe-5d43-48ad-b70a-61f3e712fcd8/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.3972473) 
>>
>> ??? #
>> ??? # If you would like to submit a bug report, please visit:
>> ??? # https://bugreport.java.com/bugreport/crash.jsp
>> ??? <https://bugreport.java.com/bugreport/crash.jsp>
>> ??? #
>>
>> ??? ---------------? S U M M A R Y ------------
>>
>> ??? Command Line: -XX:+ExecutingUnitTests -Xlog:async
>>
>> ??? Host: AArch64, 6 cores, 46G, Oracle Linux Server release 8.3
>> ??? Time: Mon May 31 22:37:04 2021 UTC elapsed time: 3.758723 seconds
>> ??? (0d 0h 0m 3s)
>>
>> ??? ---------------? T H R E A D? ---------------
>>
>> ??? Current thread (0x0000aaadf32b1e10):? Thread "AsyncLog Thread"
>> ??? [stack: 0x0000fffefdaa0000,0x0000fffefdca0000] [id=3972481]
>>
>> ??? Stack: [0x0000fffefdaa0000,0x0000fffefdca0000],     
>> sp=0x0000fffefdc9e510,? free space=2041k
>> ??? Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> ??? C=native code)
>> ??? C? [libc.so.6+0x60720]? flockfile+0x0
>> ??? V? [libjvm.so+0x1508058]     
>> LogFileOutput::write_blocking(LogDecorations const&, char const*)+0x38
>> ??? V? [libjvm.so+0x1502764]? AsyncLogWriter::run()+0x2c0
>> ??? V? [libjvm.so+0x1a49d08]? Thread::call_run()+0xf8
>> ??? V? [libjvm.so+0x1766f18]? thread_native_entry(Thread*)+0x108
>> ??? C? [libpthread.so.0+0x76e0]? start_thread+0x198
>>
>> ??? -------------
>>
>> ??? PR: https://git.openjdk.java.net/jdk/pull/4257
>> ??? <https://git.openjdk.java.net/jdk/pull/4257>
>>

From github.com+26887752+jaroslavtulach at openjdk.java.net  Tue Jun  1 09:37:21 2021
From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach)
Date: Tue, 1 Jun 2021 09:37:21 GMT
Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose
 the annotation to Java code [v4]
In-Reply-To: <Fl4YD377MK-zrYI80AoiVvkxwcde1CfyCjk_9X7SXqA=.4c2debf1-ed2b-4648-a884-7f99ff690f5b@github.com>
References: <uANHAoW40IPthSfhdkLcafIpyE_aRl1NVsXAycFZJus=.be1755a4-ec86-4efa-bfd0-26760b52ff54@github.com>
 <AmjqYY905-ud7CIbu2gf23m25yYb4Iyd5fBL6zlkuXo=.cb5cd0d9-b76d-45b9-b6ee-f080aa5f7f1c@github.com>
 <Fl4YD377MK-zrYI80AoiVvkxwcde1CfyCjk_9X7SXqA=.4c2debf1-ed2b-4648-a884-7f99ff690f5b@github.com>
Message-ID: <4uC5qHdoBI67sXAJL78KkodpfZ3ENxudrxcvyvqWbHU=.5d7827dd-30a2-4a3d-838d-e0753fdf3c54@github.com>

On Mon, 31 May 2021 12:02:13 GMT, Peter Levart <plevart at openjdk.org> wrote:

> A test could be constructed so that it would mimic the migration of an annotation from CLASS to RUNTIME retention

The test is ready for review in #4280 - I am closing this PR without integration as the change of core-libs proposed here hasn't gained enough support.

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

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

From github.com+26887752+jaroslavtulach at openjdk.java.net  Tue Jun  1 09:37:22 2021
From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach)
Date: Tue, 1 Jun 2021 09:37:22 GMT
Subject: Withdrawn: JDK-8267936: PreserveAllAnnotations option doesn't expose
 the annotation to Java code
In-Reply-To: <uANHAoW40IPthSfhdkLcafIpyE_aRl1NVsXAycFZJus=.be1755a4-ec86-4efa-bfd0-26760b52ff54@github.com>
References: <uANHAoW40IPthSfhdkLcafIpyE_aRl1NVsXAycFZJus=.be1755a4-ec86-4efa-bfd0-26760b52ff54@github.com>
Message-ID: <mQLfvkNGf61K9xm_Ur5373WNJScLviyMq49Dimg6n-E=.341b3a4a-81ed-4ae2-85f1-28b8bfc645cd@github.com>

On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM.
> 
> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission.
> 
> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on.

This pull request has been closed without being integrated.

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

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

From mdoerr at openjdk.java.net  Tue Jun  1 10:29:20 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 1 Jun 2021 10:29:20 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <DEWh5lgTw_vloM0jBdgerzIIbKeeFTR4aPLlBUUYyf0=.0f05ecda-c869-4b42-8267-846c8d4d7147@github.com>

On Tue, 1 Jun 2021 08:11:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

Builds on our old s390 machine. Thank you very much for fixing it!
Note: Some preprocessors may not support whitespaces before '#', but I believe all our supported compilers do so. So, I'm fine with it.

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

Marked as reviewed by mdoerr (Reviewer).

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

From mbaesken at openjdk.java.net  Tue Jun  1 10:51:17 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 1 Jun 2021 10:51:17 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>

On Tue, 1 Jun 2021 08:11:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

Hi, on newer s390x machines  (SLES15.2)  the value of  SYS_get_mempolicy  is  269 .
So a fix value per platform is not always correct.
However we have the define for SYS_get_mempolicy  on this SLES15.2 machine.

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

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

From vlivanov at openjdk.java.net  Tue Jun  1 11:13:25 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Jun 2021 11:13:25 GMT
Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests
 [v4]
In-Reply-To: <zfH9IBOyHaF8VXXFQ7kWN6dHDZ21d24ItWFMTfNgLUI=.976d8799-a3bb-4fdf-89ff-3760cb97985d@github.com>
References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com>
 <zfH9IBOyHaF8VXXFQ7kWN6dHDZ21d24ItWFMTfNgLUI=.976d8799-a3bb-4fdf-89ff-3760cb97985d@github.com>
Message-ID: <Rpr-uEyaZEBl4c0LnnDVCDSo4TaG5ycnrcCRwA5kT4s=.2d85b53e-b7cb-46c4-ad14-1a61f1092177@github.com>

On Mon, 31 May 2021 11:23:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests.
>> 
>> In particular: 
>>   - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; 
>>   - pass `TestBuilder` as a parameter and initiate test execution from executor; 
>>   - switch max class file version tested from 52 to 61 (`V17`); 
>>   - minor changes (cleanups, new test cases)
>> 
>> Testing:
>> - [x] vmTestbase/vm/runtime/defmeth/
>> - [x] hs-tier5-rt - hs-tier8-rt
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve README

Thanks for the reviews, Harold and David.

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

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

From vlivanov at openjdk.java.net  Tue Jun  1 11:13:26 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Jun 2021 11:13:26 GMT
Subject: Integrated: 8267095: Miscellaneous cleanups in vm.runtime.defmeth
 tests
In-Reply-To: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com>
References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com>
Message-ID: <6H9mCVlxpUQ0JjvZcDN6UVe0Jzp77JcKX1zd5mEvuwY=.e95d6ef3-0769-40e9-9743-790bba379829@github.com>

On Thu, 13 May 2021 10:14:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests.
> 
> In particular: 
>   - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; 
>   - pass `TestBuilder` as a parameter and initiate test execution from executor; 
>   - switch max class file version tested from 52 to 61 (`V17`); 
>   - minor changes (cleanups, new test cases)
> 
> Testing:
> - [x] vmTestbase/vm/runtime/defmeth/
> - [x] hs-tier5-rt - hs-tier8-rt

This pull request has now been integrated.

Changeset: 229a6e2f
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/229a6e2f3646bfb52708e4f865bd55a838b8222d
Stats:     17611 lines in 394 files changed: 323 ins; 16963 del; 325 mod

8267095: Miscellaneous cleanups in vm.runtime.defmeth tests

Reviewed-by: dholmes, hseigel

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

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

From jiefu at openjdk.java.net  Tue Jun  1 11:21:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 11:21:41 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <9VmUd6Rs8-4P992tRVdh6t8LEjPXRC1NEZwCeoxV88E=.7cba3430-3f9a-4338-b9f1-0673591cfe21@github.com>

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

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

  Check & try to use __NR_get_mempolicy first

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4277/files
  - new: https://git.openjdk.java.net/jdk/pull/4277/files/9fc63d7e..e7c7d565

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

  Stats: 17 lines in 1 file changed: 5 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4277.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4277/head:pull/4277

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

From jiefu at openjdk.java.net  Tue Jun  1 11:25:16 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 11:25:16 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
Message-ID: <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>

On Tue, 1 Jun 2021 10:48:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, on newer s390x machines (SLES15.2) the value of SYS_get_mempolicy is 269 .
> So a fix value per platform is not always correct.
> However we have the define for SYS_get_mempolicy on this SLES15.2 machine.

Okay.
Patch has been updated to check & try to use __NR_get_mempolicy first if SYS_get_mempolicy is not defined, which is suggested by @TheRealMDoerr in the JBS.
Thanks.

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

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

From david.holmes at oracle.com  Tue Jun  1 11:48:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Jun 2021 21:48:03 +1000
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
Message-ID: <b2505b8a-e804-5d79-d941-4cfbb838b95e@oracle.com>

On 1/06/2021 9:25 pm, Jie Fu wrote:
> On Tue, 1 Jun 2021 10:48:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> 
>> Hi, on newer s390x machines (SLES15.2) the value of SYS_get_mempolicy is 269 .
>> So a fix value per platform is not always correct.
>> However we have the define for SYS_get_mempolicy on this SLES15.2 machine.
> 
> Okay.
> Patch has been updated to check & try to use __NR_get_mempolicy first if SYS_get_mempolicy is not defined, which is suggested by @TheRealMDoerr in the JBS.

I don't see that suggestion in the JBS. I do see a greatly simplified 
suggestion from mbaesken:

#if !defined(SYS_get_mempolicy) && defined(S390)
#define SYS_get_mempolicy __NR_get_mempolicy
#endif

If we know that __NR_get_mempolicy is defined on the system that had the 
problem then we don't need to try and generalize things - specially if 
the actual value is not constant for a given architecture.

Thanks,
David

> Thanks.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4277
> 

From jiefu at openjdk.java.net  Tue Jun  1 12:19:19 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 12:19:19 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
Message-ID: <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>

On Tue, 1 Jun 2021 11:22:15 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > Hi, on newer s390x machines (SLES15.2) the value of SYS_get_mempolicy is 269 .
> > So a fix value per platform is not always correct.
> > However we have the define for SYS_get_mempolicy on this SLES15.2 machine.
> 
> Okay.
> Patch has been updated to check & try to use __NR_get_mempolicy first if SYS_get_mempolicy is not defined, which is suggested by @TheRealMDoerr in the JBS.
> Thanks.

Ah, using __NR_get_mempolicy is suggested by @MBaesken in the JBS.
Thanks @dholmes-ora for correcting me.

But I'm not sure if the following change is safe enough since libnuma source code also handles the case when __NR_get_mempolicy isn't defined [1] .


#if !defined(SYS_get_mempolicy) && defined(S390)
#define SYS_get_mempolicy __NR_get_mempolicy
#endif


I would suggest keeping the same logic for that case.
What do you think?
Thanks.

[1] https://github.com/numactl/numactl/blob/master/syscall.c#L29

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

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

From sjohanss at openjdk.java.net  Tue Jun  1 12:47:20 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 1 Jun 2021 12:47:20 GMT
Subject: RFR: JDK-8267839: trivial mem leak in numa
In-Reply-To: <jdETap6Eo7djsPxIF6rKqZJuAk9V8KWb7AzC-DJJ6iI=.a024d69b-1bbc-418b-9524-9e30e5491012@github.com>
References: <jdETap6Eo7djsPxIF6rKqZJuAk9V8KWb7AzC-DJJ6iI=.a024d69b-1bbc-418b-9524-9e30e5491012@github.com>
Message-ID: <e0MyS06CwncCH6MeysOBramdj9VRhCCiBvGnwJS3HOc=.10798b3a-59fc-4386-9179-fa3d64cd7840@github.com>

On Thu, 27 May 2021 08:46:00 GMT, Hamlin Li <mli at openjdk.org> wrote:

> There is a trivial mem leak in numa related code. This patch is to use a stored bitmask* rather than get a new one.

The change looks good. 

I know this pre-existing, but to me it feels a bit strange to return false if the NUMA-functions are available. Wouldn't it make more sense to return true, which would disable NUMA. This is not something we should change in this patch, just wanted to hear others opinions now when I stumbled upon this.

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

Marked as reviewed by sjohanss (Reviewer).

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

From mbaesken at openjdk.java.net  Tue Jun  1 12:57:19 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 1 Jun 2021 12:57:19 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
 <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
Message-ID: <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>

On Tue, 1 Jun 2021 12:16:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > > Hi, on newer s390x machines (SLES15.2) the value of SYS_get_mempolicy is 269 .
> > > So a fix value per platform is not always correct.
> > > However we have the define for SYS_get_mempolicy on this SLES15.2 machine.
> > 
> > 
> > Okay.
> > Patch has been updated to check & try to use __NR_get_mempolicy first if SYS_get_mempolicy is not defined, which is suggested by @TheRealMDoerr in the JBS.
> > Thanks.
> 
> Ah, using __NR_get_mempolicy is suggested by @MBaesken in the JBS.
> Thanks @dholmes-ora for correcting me.
> 
> But I'm not sure if the following change is safe enough since libnuma source code also handles the case when __NR_get_mempolicy isn't defined [1] .
> 
> ```
> #if !defined(SYS_get_mempolicy) && defined(S390)
> #define SYS_get_mempolicy __NR_get_mempolicy
> #endif
> ```
> 
> I would suggest keeping the same logic for that case.
> What do you think?
> Thanks.
> 
> [1] https://github.com/numactl/numactl/blob/master/syscall.c#L29

Hi, checking for  the existance of  SYS_get_mempolicy   AND   __NR_get_mempolicy   is  better.

Best regards, Matthias

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

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

From coleen.phillimore at oracle.com  Tue Jun  1 13:19:01 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 1 Jun 2021 09:19:01 -0400
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v2]
In-Reply-To: <stgr7jGmYoAutiAW_vZoJWjKlbmUB6e3d84rxZ14ACY=.e1493b2d-8f08-4ad2-b9c7-d2323771bab1@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com>
 <ahD_Pw1J-IevEp776izq4wDNu17-Chgh0TOGMDnXzVc=.f2eba523-dca3-446d-8c63-7442e0d96e4e@github.com>
 <stgr7jGmYoAutiAW_vZoJWjKlbmUB6e3d84rxZ14ACY=.e1493b2d-8f08-4ad2-b9c7-d2323771bab1@github.com>
Message-ID: <0b5772f9-a5a4-8267-7f73-c0f11b8376a7@oracle.com>



On 5/31/21 9:10 PM, Ioi Lam wrote:
> On Mon, 31 May 2021 22:32:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>>>
>>>   - Merge branch 'master' into 8267118-oome
>>>   - 8267118: OutOfMemoryError cannot be caught as a Throwable
>> src/hotspot/share/oops/method.cpp line 232:
>>
>>> 230:   if (do_logging) {
>>> 231:     ResourceMark rm(THREAD);
>>> 232:     log_info(exceptions)("Looking for catch handler for exception of type \"%s\" in method \"%s\"",
>> I think these should be log_debug, since this is useful for debugging but many people outside of hotspot engineers use -Xlog:exceptions.
> If the exception is not immediately caught, will this print a line for every method on the call stack that has a catch block? If so, that may be too verbose.

Thanks, Ioi.? That's what I was thinking.
Coleen

>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4266


From dcubed at openjdk.java.net  Tue Jun  1 15:24:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 15:24:31 GMT
Subject: RFR: 8268036: ProblemList gtest/AsyncLogGtest.java
Message-ID: <mwSRQiFZw01HYYaK72NAzhup3sEShq3BkuhUXzrFKoQ=.c52e8692-69e6-47a1-87fb-11b350eccb01@github.com>

Trivial fixes to ProblemList two different tests:

JDK-8268036 ProblemList gtest/AsyncLogGtest.java
JDK-8268041 ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp

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

Commit messages:
 - 8268041: ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp
 - 8268036: ProblemList gtest/AsyncLogGtest.java

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

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

From dcubed at openjdk.java.net  Tue Jun  1 15:34:23 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 15:34:23 GMT
Subject: RFR: 8268036: ProblemList gtest/AsyncLogGtest.java
In-Reply-To: <Xm5b6hWK3mVDwadp9U8b7xd6NJeefVfrjv7QGXaiLmY=.745c6b56-58cd-4725-8651-5f1cfffcb05c@github.com>
References: <mwSRQiFZw01HYYaK72NAzhup3sEShq3BkuhUXzrFKoQ=.c52e8692-69e6-47a1-87fb-11b350eccb01@github.com>
 <Xm5b6hWK3mVDwadp9U8b7xd6NJeefVfrjv7QGXaiLmY=.745c6b56-58cd-4725-8651-5f1cfffcb05c@github.com>
Message-ID: <6Jd9yEoEjA-_xKynS6RmplwVMKowPsQhLY1j8msmVuI=.2d2167b2-3e98-4096-b925-f26339bbee59@github.com>

On Tue, 1 Jun 2021 15:28:03 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Trivial fixes to ProblemList two different tests:
>> 
>> JDK-8268036 ProblemList gtest/AsyncLogGtest.java
>> JDK-8268041 ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp
>
> Looks good and trivial.

@calvinccheung - Thanks for the fast review!

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

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

From ccheung at openjdk.java.net  Tue Jun  1 15:34:22 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 1 Jun 2021 15:34:22 GMT
Subject: RFR: 8268036: ProblemList gtest/AsyncLogGtest.java
In-Reply-To: <mwSRQiFZw01HYYaK72NAzhup3sEShq3BkuhUXzrFKoQ=.c52e8692-69e6-47a1-87fb-11b350eccb01@github.com>
References: <mwSRQiFZw01HYYaK72NAzhup3sEShq3BkuhUXzrFKoQ=.c52e8692-69e6-47a1-87fb-11b350eccb01@github.com>
Message-ID: <Xm5b6hWK3mVDwadp9U8b7xd6NJeefVfrjv7QGXaiLmY=.745c6b56-58cd-4725-8651-5f1cfffcb05c@github.com>

On Tue, 1 Jun 2021 15:09:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList two different tests:
> 
> JDK-8268036 ProblemList gtest/AsyncLogGtest.java
> JDK-8268041 ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp

Looks good and trivial.

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

Marked as reviewed by ccheung (Reviewer).

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

From dcubed at openjdk.java.net  Tue Jun  1 15:34:23 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 15:34:23 GMT
Subject: Integrated: 8268036: ProblemList gtest/AsyncLogGtest.java
In-Reply-To: <mwSRQiFZw01HYYaK72NAzhup3sEShq3BkuhUXzrFKoQ=.c52e8692-69e6-47a1-87fb-11b350eccb01@github.com>
References: <mwSRQiFZw01HYYaK72NAzhup3sEShq3BkuhUXzrFKoQ=.c52e8692-69e6-47a1-87fb-11b350eccb01@github.com>
Message-ID: <2gxOFBzv4q5nFv3g95BGwVMNhhgCV7F4IPlwSw2-S0I=.ccf5ffb9-2926-426f-a2ab-818d90176628@github.com>

On Tue, 1 Jun 2021 15:09:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList two different tests:
> 
> JDK-8268036 ProblemList gtest/AsyncLogGtest.java
> JDK-8268041 ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp

This pull request has now been integrated.

Changeset: 36dc268a
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36dc268abea2522596efe830365ba4bbe6e2696c
Stats:     3 lines in 2 files changed: 3 ins; 0 del; 0 mod

8268036: ProblemList gtest/AsyncLogGtest.java
8268041: ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp

Reviewed-by: ccheung

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

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

From dcubed at openjdk.java.net  Tue Jun  1 16:01:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 16:01:20 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
Message-ID: <FHMp7SXlW_iN-CiE7-azdwlxqCm6px3Zc9OiZyJW-eU=.2c84e7ea-d492-42ef-91e1-3bed781ee0b7@github.com>

On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>> 
>> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
>> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
>> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase reader's counter before creating LogDecoration.

It looks like this failure is taking a bit of work to resolve. I've gone ahead and
ProblemListed the test. At this point we have 20 sightings in Tier[3-7]. Since
this failure is intermittent, I would want to see Tier[5-7] testing done before
the fix is integrated.

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

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

From sspitsyn at openjdk.java.net  Tue Jun  1 17:18:20 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 1 Jun 2021 17:18:20 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
Message-ID: <CAV5TPeL-T1D6uY1YZflDnhnC9YtVht-USVc88BwyXo=.c8f2db0d-1e6b-4a6c-a1db-5b7b6f724dbd@github.com>

On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
> 
> Also remove errant text added by the jframeID XSL template code:
> 
> 
> // java_thread - unchecked
> // depth - pre-checked as non-negative
> 
> 
> The first line about `jthread` is output in error.
> Only the second line about `depth` should be included.
> 
> This fix is tested with a Mach5 Tier1 job set.

Marked as reviewed by sspitsyn (Reviewer).

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

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

From iklam at openjdk.java.net  Tue Jun  1 18:38:27 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Jun 2021 18:38:27 GMT
Subject: RFR: 8267879: ClassLoaderMetaspace destructor asserts on !_frozen
Message-ID: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>

Summary: The assert was a false negative. `Metaspace::freeze()` is obsolete and should be removed.

The original reason for the `Metaspace::freeze()` API was to ensure that the safepoint portion of -Xshare:dump, i.e., `VM_PopulateDumpSharedSpace::doit()` does not call `Metaspace::allocate()`, which might cause a GC, resulting in  a deadlock.

However, since [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149), GC would happen only with the `TRAPS` version of `Metaspace::allocate()`. Since [JDK-8252685](https://bugs.openjdk.java.net/browse/JDK-8252685), `TRAPS` must be a `JavaThread`. This means that you can no longer cause a GC inside safepoint code by calling `Metaspace::allocate()`.

`Metaspace::assert_not_frozen()` was also called by the `ClassLoaderMetaspace` allocation/deallocation functions, but none of these would cause GC. Also, anyone calling these function while a safepoint is in progress (such as the ZGC code that triggered this assert) must ensure that they won't affect any code that concurrently traverses metaspace objects inside the safepoint. Such safeguard logic is already done at a higher level, we don't need the low-level asserts inside  the `ClassLoaderMetaspace` allocation/deallocation functions.

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

Commit messages:
 - 8267879: ClassLoaderMetaspace destructor asserts on !_frozen

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

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

From dcubed at openjdk.java.net  Tue Jun  1 18:55:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 18:55:26 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <a7J2c_Cg-Y69ZGZBuNiUJmJvnEw0PYN84C3JHRaQDhA=.cde93a9d-1644-455b-b4ff-f269c0ec65c4@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
 <a7J2c_Cg-Y69ZGZBuNiUJmJvnEw0PYN84C3JHRaQDhA=.cde93a9d-1644-455b-b4ff-f269c0ec65c4@github.com>
Message-ID: <1FMAjSHJcGt2gZuT15gF1iqH2_Cnc3U821a7ZFmcSNw=.249cc22c-e982-4fa2-bd94-3e3ddc818cfd@github.com>

On Mon, 31 May 2021 06:41:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
>> 
>> Also remove errant text added by the jframeID XSL template code:
>> 
>> 
>> // java_thread - unchecked
>> // depth - pre-checked as non-negative
>> 
>> 
>> The first line about `jthread` is output in error.
>> Only the second line about `depth` should be included.
>> 
>> This fix is tested with a Mach5 Tier1 job set.
>
> Marked as reviewed by rehn (Reviewer).

@robehn, @dholmes-ora and @sspitsyn - Thanks for the reviews!

> It is rather confusing though as I couldn't figure out why some functions
> have the threadsList-handle as part of the code generated via the XML
> file, and some have it in the jvmtiEnv part of the code - e.g. compare
> SetThreadLocalStorage and GetThreadLocalStorage.

That would be an historical question for Robert Field. :-)
Definitely not something I want to deal with in this change.

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

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

From dcubed at openjdk.java.net  Tue Jun  1 18:55:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 18:55:27 GMT
Subject: Integrated: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
Message-ID: <jQfrwzET8BdUkLEDYV18HwBLeIiSgYE_3uZmnWwoJP4=.bacecbfd-567f-4d2a-892e-1a79822f26db@github.com>

On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
> 
> Also remove errant text added by the jframeID XSL template code:
> 
> 
> // java_thread - unchecked
> // depth - pre-checked as non-negative
> 
> 
> The first line about `jthread` is output in error.
> Only the second line about `depth` should be included.
> 
> This fix is tested with a Mach5 Tier1 job set.

This pull request has now been integrated.

Changeset: 40e4171f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40e4171f562da2f6a507efc7ad359e298199ed71
Stats:     91 lines in 3 files changed: 0 ins; 52 del; 39 mod

8264800: cleanup Threads_lock comments in JVM/TI function headers

Reviewed-by: coleenp, rehn, dholmes, sspitsyn

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

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

From coleenp at openjdk.java.net  Tue Jun  1 19:29:48 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 1 Jun 2021 19:29:48 GMT
Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable [v2]
In-Reply-To: <q7IPuRvC1xbo8U1nuhe6Wre7QYw3HuDFM-kSt4V5n08=.2f3190bd-8dac-4165-afbc-94520053b814@github.com>
References: <dvK8J-bQLIuE3RCQAP1NIJmFjr0Hxf1iOh2fBLUU880=.a80ebffe-6b5e-4952-9b8b-cfc59c2c2d03@github.com>
 <q7IPuRvC1xbo8U1nuhe6Wre7QYw3HuDFM-kSt4V5n08=.2f3190bd-8dac-4165-afbc-94520053b814@github.com>
Message-ID: <pUdEGQmJfGNX8usqBjj-TFt9StT52gsPZXT0YESTPqM=.24ca1a68-4fec-4276-92ed-6508f19c4fe3@github.com>

On Mon, 17 May 2021 06:00:33 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ID2KlassTable* instead of ID2KlassTable *

This looks good to me.

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

Marked as reviewed by coleenp (Reviewer).

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

From pchilanomate at openjdk.java.net  Tue Jun  1 19:30:26 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Tue, 1 Jun 2021 19:30:26 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
Message-ID: <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>

On Fri, 28 May 2021 07:45:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - Fix

Hi Robbin,

I think your patch looks good and fixes the issue with is_locked(). 
Based on the root cause it seems another simpler solution would have been to add a fence between claim_handshake() and can_process_handshake() to make sure the target sees the write to _owner before we read a handshake safe state. If the issue is that _owner should be only use for debug builds or that the fence should have been in Mutex class and we don't want to affect all other cases, then we could use _active_handshaker instead of _owner. That way we could also keep the while loop in try_process() to process multiple operations at a time, and don't worry about the peek vs pop issue.

Thanks,
Patricio

src/hotspot/share/runtime/handshake.cpp line 330:

> 328:   // closure are visible to the VMThread/Handshaker after it reads
> 329:   // that the operation has completed.
> 330:   Atomic::dec(&_pending_threads);

Why do we need a full fence instead of a release as before?

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

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

From iklam at openjdk.java.net  Tue Jun  1 19:54:16 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Jun 2021 19:54:16 GMT
Subject: RFR: 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java timed
 out
Message-ID: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>

[JDK-8267347](https://bugs.openjdk.java.net/browse/JDK-8267347) doubles the amount of time spent inside this test. It's better to split the test into two parts as suggested by @iignatev in https://github.com/openjdk/jdk/pull/4198#discussion_r641343393

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

Commit messages:
 - [TESTBUG] cds DynamicLoaderConstraintsTest.java timed out

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

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

From yyang at openjdk.java.net  Tue Jun  1 20:01:21 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 1 Jun 2021 20:01:21 GMT
Subject: Integrated: 8267089: Use typedef KVHashtable for ID2KlassTable
In-Reply-To: <dvK8J-bQLIuE3RCQAP1NIJmFjr0Hxf1iOh2fBLUU880=.a80ebffe-6b5e-4952-9b8b-cfc59c2c2d03@github.com>
References: <dvK8J-bQLIuE3RCQAP1NIJmFjr0Hxf1iOh2fBLUU880=.a80ebffe-6b5e-4952-9b8b-cfc59c2c2d03@github.com>
Message-ID: <B_sF3ADil913QIub11iyjcK80GS94TRhGYEk-3pdV4Q=.fb229ef8-c6ce-4dc5-ac2c-20b880b4061a@github.com>

On Thu, 13 May 2021 07:08:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

> While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead.

This pull request has now been integrated.

Changeset: c2c0208d
Author:    Yi Yang <yyang at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c2c0208dfd986eef19a65727e875b023fb595436
Stats:     10 lines in 2 files changed: 3 ins; 5 del; 2 mod

8267089: Use typedef KVHashtable for ID2KlassTable

Reviewed-by: iklam, coleenp

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

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

From darcy at openjdk.java.net  Tue Jun  1 20:09:48 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Jun 2021 20:09:48 GMT
Subject: RFR: 8266530: HotSpot changes for JEP 306 [v12]
In-Reply-To: <XuihfSKHXjSiEbfqw6SdlnkyibJw-s58fBhXnFKJvq0=.c53105f0-f597-446d-896a-7c1b6fddb7ba@github.com>
References: <XuihfSKHXjSiEbfqw6SdlnkyibJw-s58fBhXnFKJvq0=.c53105f0-f597-446d-896a-7c1b6fddb7ba@github.com>
Message-ID: <kCCzLe38bXVGvnzKM8AQ_EndsuANUpS5CebPX_O3wKU=.cf5a0ae8-e907-4a83-94b4-8b75164b9a39@github.com>

> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics.
> 
> JEP 306 is considering the following changes to the JVMS: 
> 
> 1) Require "strict" floating-point evaluation in all circumstances.
> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier.
> 
> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version.
> 
> The tests verify  "abstract strictfp" triggers a ClassFormatError  for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.)
> 
> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831.
> 
> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other:
>  * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac.
>  *  since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation.

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 15 additional commits since the last revision:

 - Merge branch 'master' into 8266530
 - Merge branch 'master' into 8266530
 - Merge branch 'master' into 8266530
 - Merge branch 'master' into 8266530
 - Fix typo found by @hseigel.
 - Merge branch 'master' into 8266530
 - Respond to review feedback.
 - Merge branch 'master' into 8266530
 - Restore previous is_strict cdoe in method.hpp.
 - Merge branch 'master' into 8266530
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/c764f571...dea9bff9

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3891/files
  - new: https://git.openjdk.java.net/jdk/pull/3891/files/e1acb870..dea9bff9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=10-11

  Stats: 20778 lines in 473 files changed: 1540 ins; 18461 del; 777 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3891.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891

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

From coleenp at openjdk.java.net  Tue Jun  1 20:21:16 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 1 Jun 2021 20:21:16 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
Message-ID: <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>

On Tue, 1 Jun 2021 02:41:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>> 
>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>> 
>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>> 
>> Testing: tiers 1-3, plus the new test
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>   feedback from @coleenp @iklam

Can you reduce the amount of logging code please?

src/hotspot/share/oops/method.cpp line 232:

> 230:     ResourceMark rm(THREAD);
> 231:     log_debug(exceptions)("Looking for catch handler for exception of type \"%s\" in method \"%s\"",
> 232:                           ex_klass == NULL ? "NULL" : ex_klass->external_name(), mh()->name()->as_C_string());

You don't need () with mh().  just mh->

src/hotspot/share/oops/method.cpp line 261:

> 259:           ResourceMark rm(THREAD);
> 260:           log_info(exceptions)("Found catch-all handler for exception of type \"%s\" in method \"%s\" at BCI: %d",
> 261:                                ex_klass == NULL ? "NULL" : ex_klass->external_name(), mh()->name()->as_C_string(), handler_bci);

Same here.

src/hotspot/share/oops/method.cpp line 285:

> 283:         Klass* k = pool->klass_at(klass_index, THREAD);
> 284:         if (HAS_PENDING_EXCEPTION) {
> 285:         if (log_is_enabled(Debug, exceptions)) {

Technically, this would be interesting enough to be log_info level.

src/hotspot/share/oops/method.cpp line 300:

> 298:             log_info(exceptions)("Found matching handler for exception of type \"%s\" in method \"%s\" at BCI: %d",
> 299:                                  ex_klass == NULL ? "NULL" : ex_klass->external_name(), mh()->name()->as_C_string(), handler_bci);
> 300:           }

There's so much extra code added with this logging.  It's hard to follow as it is. Could you just have the log_info level output in both this and the case above where you find the handler, here and above?  debug level logging will include info level debugging.

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

Changes requested by coleenp (Reviewer).

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

From dcubed at openjdk.java.net  Tue Jun  1 20:52:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 20:52:40 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>

> The Thread-SMR project added counter based tests for various APIs.
> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
> 
> Time based tests are more appropriate for stress kits so I'm
> updating the counter based tests to be time based instead.
> 
> Two of the updated tests have shaken out failures that are tracked by:
> 
>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
> 
>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
> 
> These updated tests are tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-4].

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Apply @plummercj code review fix from JDK-8265153 to this review also.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4237/files
  - new: https://git.openjdk.java.net/jdk/pull/4237/files/8ec5caed..2ab79a2c

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

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

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

From dcubed at openjdk.java.net  Tue Jun  1 21:30:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 21:30:38 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
Message-ID: <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>

On Fri, 28 May 2021 07:45:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - Fix

Changes requested by dcubed (Reviewer).

I've stopped my review because I realized that I have gotten confused by
the `peek()` operation that actually appears to be searching for a match
rather than peeking at the head (or tail) of the queue. My brain is no longer
clear on what your operations are. Sorry.

src/hotspot/share/runtime/handshake.cpp line 429:

> 427:   assert(_handshakee == Thread::current(), "Must be called by self");
> 428:   assert(_lock.owned_by_self(), "Lock must be held");
> 429:   return _queue.peek();

`get_op_for_self()` name does not match the `peek()` operation.
The new name should be `peek_op_for_self()`.

src/hotspot/share/runtime/handshake.cpp line 445:

> 443:   assert(_handshakee != Thread::current(), "Must not be called by self");
> 444:   assert(_lock.owned_by_self(), "Lock must be held");
> 445:   return _queue.peek(non_self_queue_filter);

`get_op()` name does not match the peek() operation.
The new name should be `peek_op()`.

src/hotspot/share/runtime/handshake.cpp line 452:

> 450:   MatchOp mo(op);
> 451:   HandshakeOperation* ret = _queue.pop(mo);
> 452:   assert(ret == op, "OP missing from queue");

Perhaps this for the assert() mesg:
`  assert(ret == op, "popped op must match requested op.");

Also, I would name this one `pop_op()` instead of `remove_op()`.

src/hotspot/share/runtime/handshake.cpp line 483:

> 481:         HandleMark hm(_handshakee);
> 482:         PreserveExceptionMark pem(_handshakee);
> 483:         op->do_handshake(_handshakee); // acquire, op removed after

Why `acquire`? Perhaps:
`// peek and handshake with op; op removed after`

src/hotspot/share/runtime/handshake.cpp line 489:

> 487:         // The destructor ~PreserveExceptionMark touches the exception oop so it must not be executed,
> 488:         // since a safepoint may be in-progress when returning from the async handshake.
> 489:         op->do_handshake(_handshakee); // acquire, op removed after

Why acquire? Perhaps:
// peek and handshake with op; op removed after

src/hotspot/share/runtime/handshake.cpp line 583:

> 581: 
> 582:   set_active_handshaker(current_thread);
> 583:   op->do_handshake(_handshakee); // acquire, op removed after

Why acquire? Perhaps:
// peek and handshake with op; op removed after

src/hotspot/share/runtime/handshake.hpp line 107:

> 105:   void remove_op(HandshakeOperation* op);
> 106: 
> 107:   void set_active_handshaker(Thread* thread) { Atomic::store(&_active_handshaker, thread); }

Should:
```Thread* _active_handshaker;```
on L89 above be:
```Thread* volatile _active_handshaker;```

src/hotspot/share/utilities/filterQueue.inline.hpp line 127:

> 125:   do {
> 126:     if (match_func(cur->_data)) {
> 127:       match = cur;

Hmmm.... I was expecting a break after this match.
Is there a reason to continue the loop?

But now I'm realizing that I'm confused since this is called `peek()`, but
it's not really peeking at the head of the queue. It is searching the entire
queue for a match.

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

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

From dcubed at openjdk.java.net  Tue Jun  1 21:30:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 21:30:41 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
Message-ID: <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>

On Tue, 1 Jun 2021 19:23:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into handshakee
>>  - Small update
>>  - Merge branch 'master' into handshakee
>>  - Fix
>
> src/hotspot/share/runtime/handshake.cpp line 330:
> 
>> 328:   // closure are visible to the VMThread/Handshaker after it reads
>> 329:   // that the operation has completed.
>> 330:   Atomic::dec(&_pending_threads);
> 
> Why do we need a full fence instead of a release as before?

And does the comment on L326 now need to be updated?

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

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

From dholmes at openjdk.java.net  Tue Jun  1 21:47:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 21:47:28 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
 <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>
Message-ID: <_CJI81Mjkg1v9seAaznne2R7xxiYsXLDRpy-UjpgyPU=.21000cb0-81c1-48e3-86f8-4ee1f50ab442@github.com>

On Tue, 1 Jun 2021 20:14:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>>   feedback from @coleenp @iklam
>
> src/hotspot/share/oops/method.cpp line 300:
> 
>> 298:             log_info(exceptions)("Found matching handler for exception of type \"%s\" in method \"%s\" at BCI: %d",
>> 299:                                  ex_klass == NULL ? "NULL" : ex_klass->external_name(), mh()->name()->as_C_string(), handler_bci);
>> 300:           }
> 
> There's so much extra code added with this logging.  It's hard to follow as it is. Could you just have the log_info level output in both this and the case above where you find the handler, here and above?  debug level logging will include info level debugging.

The problem is that debug logging is step-by-step information, while the Info logging is a complete statement. So the Info message does not fit with the previous debug messages, hence the either-or approach.

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

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

From dholmes at openjdk.java.net  Tue Jun  1 21:50:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 21:50:49 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
 <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>
Message-ID: <fuZMyLRvqdjdQZap2qNCpNz71USy0CJQgiSjV9tzv4s=.399df5ea-6577-4a41-9a80-4577db6597fe@github.com>

On Tue, 1 Jun 2021 20:15:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>>   feedback from @coleenp @iklam
>
> src/hotspot/share/oops/method.cpp line 285:
> 
>> 283:         Klass* k = pool->klass_at(klass_index, THREAD);
>> 284:         if (HAS_PENDING_EXCEPTION) {
>> 285:         if (log_is_enabled(Debug, exceptions)) {
> 
> Technically, this would be interesting enough to be log_info level.

Perhaps, but again making it fit and provide sufficient contextual information is awkward and the throw is already captured at the Info level. So I would hope that if someone saw the unexpected throw logging they would use that as a cue to turn on debug logging to get more information.

Logging is really, really subjective - painfully so.

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

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

From dholmes at openjdk.java.net  Tue Jun  1 21:57:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 21:57:13 GMT
Subject: RFR: 8266950: Remove vestigial support for non-strict
 floating-point execution [v8]
In-Reply-To: <bfkZYvuMzpOUooZcraGOseLGSzHGqTJWBdD_sdbiX-I=.2772f552-3614-4f85-89a4-128a1165c670@github.com>
References: <bfkZYvuMzpOUooZcraGOseLGSzHGqTJWBdD_sdbiX-I=.2772f552-3614-4f85-89a4-128a1165c670@github.com>
Message-ID: <O_aE1uKnCFiZtfnCLOuq1ogg5559U5pVXIShXF4Nuao=.91111dfe-4520-40b1-b3af-79a86f9ad677@github.com>

> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly.
> 
> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

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

 - Merge branch 'master' into jep-306
 - Merge branch 'master' into jep-306
 - Remove dead code on aarch64
 - Merge branch 'master' into jep-306
 - The code for strict handling only applies to doubles.
 - Add missing space
 - lir_div_strictfp and lir_mul_strictfp
 - Removed divDPR_reg_round as it has a false predicate and so is now unused
 - Revert classFileParser changes as they will be handled by JDK-8266530
 - 8266530: HotSpot changes for JEP 306
   All methods are now implicitly strictfp so all code generation etc
   uses the strict form.
   There are still some names that include "strict" that could potentially
   be renamed to rmeove it, but the fact we have to have strict fp semantics
   is still important on some platforms, so the names help reinforce that IMO.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3991/files
  - new: https://git.openjdk.java.net/jdk/pull/3991/files/3ce17c29..d9015f58

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=06-07

  Stats: 23479 lines in 782 files changed: 3115 ins; 18957 del; 1407 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3991.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991

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

From lmesnik at openjdk.java.net  Tue Jun  1 22:04:52 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 1 Jun 2021 22:04:52 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly
Message-ID: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>

8266337: ThreadTimesClosure doesn't handle exceptions properly

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

Commit messages:
 - 8266337: ThreadTimesClosure doesn't handle exceptions properly

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

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

From darcy at openjdk.java.net  Tue Jun  1 22:05:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Jun 2021 22:05:40 GMT
Subject: Integrated: 8266530: HotSpot changes for JEP 306
In-Reply-To: <XuihfSKHXjSiEbfqw6SdlnkyibJw-s58fBhXnFKJvq0=.c53105f0-f597-446d-896a-7c1b6fddb7ba@github.com>
References: <XuihfSKHXjSiEbfqw6SdlnkyibJw-s58fBhXnFKJvq0=.c53105f0-f597-446d-896a-7c1b6fddb7ba@github.com>
Message-ID: <3yM9fVzoukqevDyF09Rm-6tI5_3oIR-flUsBFZA9Jjk=.4948b038-f992-4e44-bdb9-c5616219acc4@github.com>

On Wed, 5 May 2021 20:57:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics.
> 
> JEP 306 is considering the following changes to the JVMS: 
> 
> 1) Require "strict" floating-point evaluation in all circumstances.
> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier.
> 
> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version.
> 
> The tests verify  "abstract strictfp" triggers a ClassFormatError  for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.)
> 
> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831.
> 
> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other:
>  * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac.
>  *  since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation.

This pull request has now been integrated.

Changeset: 8624cb53
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8624cb53cdf34555ca76ed8ea89878b6e54cd769
Stats:     420 lines in 6 files changed: 417 ins; 0 del; 3 mod

8266530: HotSpot changes for JEP 306

Reviewed-by: dholmes, hseigel

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

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

From dholmes at openjdk.java.net  Tue Jun  1 22:07:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 22:07:32 GMT
Subject: RFR: 8266950: Remove vestigial support for non-strict
 floating-point execution [v9]
In-Reply-To: <bfkZYvuMzpOUooZcraGOseLGSzHGqTJWBdD_sdbiX-I=.2772f552-3614-4f85-89a4-128a1165c670@github.com>
References: <bfkZYvuMzpOUooZcraGOseLGSzHGqTJWBdD_sdbiX-I=.2772f552-3614-4f85-89a4-128a1165c670@github.com>
Message-ID: <SGlgjivzCrQtsaEKRQcJipkiDQgQN_JG5wbwJtfybs4=.92e0ad77-9937-4e39-a50c-efaa60d983dd@github.com>

> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly.
> 
> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

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

 - Merge branch 'master' into jep-306
 - Merge branch 'master' into jep-306
 - Merge branch 'master' into jep-306
 - Remove dead code on aarch64
 - Merge branch 'master' into jep-306
 - The code for strict handling only applies to doubles.
 - Add missing space
 - lir_div_strictfp and lir_mul_strictfp
 - Removed divDPR_reg_round as it has a false predicate and so is now unused
 - Revert classFileParser changes as they will be handled by JDK-8266530
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/a7f064b9...1688bdae

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3991/files
  - new: https://git.openjdk.java.net/jdk/pull/3991/files/d9015f58..1688bdae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=07-08

  Stats: 585 lines in 28 files changed: 529 ins; 7 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3991.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991

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

From dholmes at openjdk.java.net  Tue Jun  1 22:07:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 22:07:33 GMT
Subject: Integrated: 8266950: Remove vestigial support for non-strict
 floating-point execution
In-Reply-To: <bfkZYvuMzpOUooZcraGOseLGSzHGqTJWBdD_sdbiX-I=.2772f552-3614-4f85-89a4-128a1165c670@github.com>
References: <bfkZYvuMzpOUooZcraGOseLGSzHGqTJWBdD_sdbiX-I=.2772f552-3614-4f85-89a4-128a1165c670@github.com>
Message-ID: <JQ37dUK1lbdUCRDIWz8CAzMECdARHwkYBUhvPyNKEbs=.075a959c-6c37-4717-a4ec-df8f4d96fa3f@github.com>

On Wed, 12 May 2021 05:33:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly.
> 
> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: cb7128b5
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb7128b58e02fa0a8dd69e9a9bdd587aa8052d73
Stats:     324 lines in 43 files changed: 15 ins; 231 del; 78 mod

8266950: Remove vestigial support for non-strict floating-point execution

Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Reviewed-by: vlivanov, kvn

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

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

From dholmes at openjdk.java.net  Tue Jun  1 22:46:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 22:46:29 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <_dj-ctWdVqcFmAgThgQzG-YTnj875WRe8N0gVo1oSGI=.c743c8f8-f6f0-403d-adab-2605adac1012@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

Hi Leonid,

This change looks good to me.

Thanks,
David

src/hotspot/share/services/management.cpp line 1708:

> 1706:     Threads::threads_do(&ttc);
> 1707:   }
> 1708:   ttc.do_unlocked(THREAD);

At first I thought this should use CHECK_0 not THREAD so it will return zero when an exception occurs. But this goes straight back to Java code so the exception will propagate and the return value can't be examined.

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

Marked as reviewed by dholmes (Reviewer).

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

From jiefu at openjdk.java.net  Tue Jun  1 23:05:30 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 23:05:30 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
 <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
 <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>
Message-ID: <v4UmJdg_ij2nQ8I9LOaz_bYGHIX_AciFDKTM5OTLBJY=.22936ad6-a1ca-4eb8-a796-bd3045e036ce@github.com>

On Tue, 1 Jun 2021 12:54:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, checking for the existance of SYS_get_mempolicy AND __NR_get_mempolicy is better.

So are you fine with the latest change?
Thanks.

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

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

From sspitsyn at openjdk.java.net  Tue Jun  1 23:12:31 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 1 Jun 2021 23:12:31 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <P5pWcbf5FAVT3zwU-UV3XOc06FvRTUe8ezxPG65RzwU=.84b18227-1d74-47ed-988f-53e99c109c7f@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

Hi Leonid,

This looks good to me.
One thing to consider is to use `os::strdup_check_oom` instead of `os::strdup`.
The os::strdup can return NULL.

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From coleenp at openjdk.java.net  Tue Jun  1 23:16:28 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 1 Jun 2021 23:16:28 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
Message-ID: <K_76yeHXW0IfEUFS60E2RSK0yKwWED5rop_Pl8QShLQ=.8fc66a8e-6170-499c-873b-50792b70816b@github.com>

On Tue, 1 Jun 2021 02:41:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>> 
>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>> 
>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>> 
>> Testing: tiers 1-3, plus the new test
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>   feedback from @coleenp @iklam

Changes requested by coleenp (Reviewer).

test/hotspot/jtreg/runtime/Throwable/TestCatchThrowableOOM.java line 29:

> 27:  * @summary Test catching Throwable doesn't trigger OOME
> 28:  * @library /test/lib
> 29:  * @run driver TestCatchThrowableOOM

Do you  want to run this with -Xlog:exceptions=debug to verify that the debug statements print.  I don't think you should verify them if you don't want to but make sure that the code is exercised going forward.

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

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

From ccheung at openjdk.java.net  Tue Jun  1 23:16:31 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 1 Jun 2021 23:16:31 GMT
Subject: RFR: 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java
 timed out
In-Reply-To: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
References: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
Message-ID: <U4wmT9LQkTrUc2voZeE5NMSa7vQ8xO__C1Zg0jqowjg=.89fc0a43-2019-467d-8474-189de40760a6@github.com>

On Tue, 1 Jun 2021 19:35:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [JDK-8267347](https://bugs.openjdk.java.net/browse/JDK-8267347) doubles the amount of time spent inside this test. It's better to split the test into two parts as suggested by @iignatev in https://github.com/openjdk/jdk/pull/4198#discussion_r641343393

Looks good. Couple of nits below.

test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java line 43:

> 41:  * @requires vm.cds.custom.loaders
> 42:  * @summary Test class loader constraint checks for archived classes (dynamic archive) with custom class loader
> 43:  * @bug 8267347

Please also add the current bug id.

test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java line 40:

> 38:  * @requires vm.cds.custom.loaders
> 39:  * @summary Test class loader constraint checks for archived classes with custom class loader
> 40:  * @bug 8267347

You've omitted the 8267754 bug id. Please also add the current bug id.

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

Marked as reviewed by ccheung (Reviewer).

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

From coleenp at openjdk.java.net  Tue Jun  1 23:16:29 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 1 Jun 2021 23:16:29 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <fuZMyLRvqdjdQZap2qNCpNz71USy0CJQgiSjV9tzv4s=.399df5ea-6577-4a41-9a80-4577db6597fe@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
 <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>
 <fuZMyLRvqdjdQZap2qNCpNz71USy0CJQgiSjV9tzv4s=.399df5ea-6577-4a41-9a80-4577db6597fe@github.com>
Message-ID: <LUW1eSyx9YCbiNYPRtRrMSf4NKK0KssLzeuPE0VPafg=.ee5e9f54-23d2-444f-bd19-d37ddf046281@github.com>

On Tue, 1 Jun 2021 21:47:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 285:
>> 
>>> 283:         Klass* k = pool->klass_at(klass_index, THREAD);
>>> 284:         if (HAS_PENDING_EXCEPTION) {
>>> 285:         if (log_is_enabled(Debug, exceptions)) {
>> 
>> Technically, this would be interesting enough to be log_info level.
>
> Perhaps, but again making it fit and provide sufficient contextual information is awkward and the throw is already captured at the Info level. So I would hope that if someone saw the unexpected throw logging they would use that as a cue to turn on debug logging to get more information.
> 
> Logging is really, really subjective - painfully so.

ok.

>> src/hotspot/share/oops/method.cpp line 300:
>> 
>>> 298:             log_info(exceptions)("Found matching handler for exception of type \"%s\" in method \"%s\" at BCI: %d",
>>> 299:                                  ex_klass == NULL ? "NULL" : ex_klass->external_name(), mh()->name()->as_C_string(), handler_bci);
>>> 300:           }
>> 
>> There's so much extra code added with this logging.  It's hard to follow as it is. Could you just have the log_info level output in both this and the case above where you find the handler, here and above?  debug level logging will include info level debugging.
>
> The problem is that debug logging is step-by-step information, while the Info logging is a complete statement. So the Info message does not fit with the previous debug messages, hence the either-or approach.

Logging is supposed to be non-invasive in the source code, which is why it was defined ideally to have one line like log_info(tag)(string)
Here it seems to dominate the code in this method.  Anything to make it shorter and less invasive would be better so that you can see how the code is actually finds the exception handler.  I only made a small request for simplification.  I think the formatting of the log messages wouldn't be bad if the info line is printed rather than the debug line.

[0.208s][debug][exceptions] Looking for catch handler for exception of type "java.lang.Error" in method "main"
[0.208s][debug][exceptions] - checking exception table entry for BCI 0 to 3
[0.208s][debug][exceptions] - entry covers throw point BCI 0
[0.208s][debug][exceptions] - found catch-all handler at BCI: 14

Would be:

[0.208s][debug][exceptions] Looking for catch handler for exception of type "java.lang.Error" in method "main"
[0.208s][debug][exceptions] - checking exception table entry for BCI 0 to 3
[0.208s][debug][exceptions] - entry covers throw point BCI 0
[0.198s][info     ][exceptions] Found catch-all handler for exception of type "java.lang.Error" in method "main" at BCI: 14

I don't think this looks bad at all and worth not having special if statement for debug/info logging.  That's 6 lines saved in this 96 line function.

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

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

From dholmes at openjdk.java.net  Tue Jun  1 23:20:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 23:20:57 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v4]
In-Reply-To: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
Message-ID: <pgynhfUl1AkStzw282GfioFKfpqdzIws79iS0RuoFRw=.780549f7-f51b-4d05-a832-fe7fc5d8dbc7@github.com>

> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
> 
> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
> 
> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
> 
> Testing: tiers 1-3, plus the new test
> 
> Thanks,
> David

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

  Fix mh() usage

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4266/files
  - new: https://git.openjdk.java.net/jdk/pull/4266/files/57561f1d..ce8496bd

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

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

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

From dholmes at openjdk.java.net  Tue Jun  1 23:24:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 23:24:30 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <9VmUd6Rs8-4P992tRVdh6t8LEjPXRC1NEZwCeoxV88E=.7cba3430-3f9a-4338-b9f1-0673591cfe21@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <9VmUd6Rs8-4P992tRVdh6t8LEjPXRC1NEZwCeoxV88E=.7cba3430-3f9a-4338-b9f1-0673591cfe21@github.com>
Message-ID: <jL3gX6A4HU3GM-uNhjAhZGuk_Nd2EDM14-o2Qx7Bz2I=.0a363066-b17d-4dc0-873e-bacd28edee92@github.com>

On Tue, 1 Jun 2021 11:21:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check & try to use __NR_get_mempolicy first

I would prefer to only use what we need to fix the problem on the "old" system that it was observed rather than trying to generalize this for arbitrary/unknown old versions of Linux. Otherwise we can never know when it is okay to remove this code.

David

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

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

From dholmes at openjdk.java.net  Tue Jun  1 23:29:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 23:29:28 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <LUW1eSyx9YCbiNYPRtRrMSf4NKK0KssLzeuPE0VPafg=.ee5e9f54-23d2-444f-bd19-d37ddf046281@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
 <ejZTdJxOTXf2j4Fr3PomgjKBPoo-IJL1gq-3u_Bab9o=.4bc00972-fb6b-4f06-b072-f5d3eb554bbe@github.com>
 <fuZMyLRvqdjdQZap2qNCpNz71USy0CJQgiSjV9tzv4s=.399df5ea-6577-4a41-9a80-4577db6597fe@github.com>
 <LUW1eSyx9YCbiNYPRtRrMSf4NKK0KssLzeuPE0VPafg=.ee5e9f54-23d2-444f-bd19-d37ddf046281@github.com>
Message-ID: <h0jf7GWXqQmb-4GaP4Rjf_feVHeudWNTrNNc4xdpof4=.088409bc-cfd0-45e7-a182-e9e54a45e960@github.com>

On Tue, 1 Jun 2021 23:08:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The problem is that debug logging is step-by-step information, while the Info logging is a complete statement. So the Info message does not fit with the previous debug messages, hence the either-or approach.
>
> Logging is supposed to be non-invasive in the source code, which is why it was defined ideally to have one line like log_info(tag)(string)
> Here it seems to dominate the code in this method.  Anything to make it shorter and less invasive would be better so that you can see how the code is actually finds the exception handler.  I only made a small request for simplification.  I think the formatting of the log messages wouldn't be bad if the info line is printed rather than the debug line.
> 
> [0.208s][debug][exceptions] Looking for catch handler for exception of type "java.lang.Error" in method "main"
> [0.208s][debug][exceptions] - checking exception table entry for BCI 0 to 3
> [0.208s][debug][exceptions] - entry covers throw point BCI 0
> [0.208s][debug][exceptions] - found catch-all handler at BCI: 14
> 
> Would be:
> 
> [0.208s][debug][exceptions] Looking for catch handler for exception of type "java.lang.Error" in method "main"
> [0.208s][debug][exceptions] - checking exception table entry for BCI 0 to 3
> [0.208s][debug][exceptions] - entry covers throw point BCI 0
> [0.198s][info     ][exceptions] Found catch-all handler for exception of type "java.lang.Error" in method "main" at BCI: 14
> 
> I don't think this looks bad at all and worth not having special if statement for debug/info logging.  That's 6 lines saved in this 96 line function.

Okay I will redo this.

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

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

From dholmes at openjdk.java.net  Tue Jun  1 23:29:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 23:29:29 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <K_76yeHXW0IfEUFS60E2RSK0yKwWED5rop_Pl8QShLQ=.8fc66a8e-6170-499c-873b-50792b70816b@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
 <K_76yeHXW0IfEUFS60E2RSK0yKwWED5rop_Pl8QShLQ=.8fc66a8e-6170-499c-873b-50792b70816b@github.com>
Message-ID: <8PPeXX_Zb5hLbudIbarOsqjbjyie6GI939HUj8ep3LE=.8845b3a4-2547-46e1-af90-206ba0c37995@github.com>

On Tue, 1 Jun 2021 23:13:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>>   feedback from @coleenp @iklam
>
> test/hotspot/jtreg/runtime/Throwable/TestCatchThrowableOOM.java line 29:
> 
>> 27:  * @summary Test catching Throwable doesn't trigger OOME
>> 28:  * @library /test/lib
>> 29:  * @run driver TestCatchThrowableOOM
> 
> Do you  want to run this with -Xlog:exceptions=debug to verify that the debug statements print.  I don't think you should verify them if you don't want to but make sure that the code is exercised going forward.

The test itself doesn't need logging, the exec'd VM has all the logging enabled.

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

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

From jiefu at openjdk.java.net  Tue Jun  1 23:30:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Jun 2021 23:30:38 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <jL3gX6A4HU3GM-uNhjAhZGuk_Nd2EDM14-o2Qx7Bz2I=.0a363066-b17d-4dc0-873e-bacd28edee92@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <9VmUd6Rs8-4P992tRVdh6t8LEjPXRC1NEZwCeoxV88E=.7cba3430-3f9a-4338-b9f1-0673591cfe21@github.com>
 <jL3gX6A4HU3GM-uNhjAhZGuk_Nd2EDM14-o2Qx7Bz2I=.0a363066-b17d-4dc0-873e-bacd28edee92@github.com>
Message-ID: <XlWmlMZaN_9uMkUbT3MR0lbbKklIikVeMRsJEu2l6L0=.6f73b4bc-8146-4b01-8de7-a18f22214355@github.com>

On Tue, 1 Jun 2021 23:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Otherwise we can never know when it is okay to remove this code.

This sounds reasonable.
Will update it later.
Thanks.

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

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

From iklam at openjdk.java.net  Tue Jun  1 23:30:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Jun 2021 23:30:42 GMT
Subject: RFR: 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java
 timed out
In-Reply-To: <U4wmT9LQkTrUc2voZeE5NMSa7vQ8xO__C1Zg0jqowjg=.89fc0a43-2019-467d-8474-189de40760a6@github.com>
References: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
 <U4wmT9LQkTrUc2voZeE5NMSa7vQ8xO__C1Zg0jqowjg=.89fc0a43-2019-467d-8474-189de40760a6@github.com>
Message-ID: <EtZKigUfvSOMhqMJPYN0e9s5vOzKoQRSQvHmEm3bwRQ=.3fd26d69-08d0-49c9-9920-c9f1e599a610@github.com>

On Tue, 1 Jun 2021 23:13:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> [JDK-8267347](https://bugs.openjdk.java.net/browse/JDK-8267347) doubles the amount of time spent inside this test. It's better to split the test into two parts as suggested by @iignatev in https://github.com/openjdk/jdk/pull/4198#discussion_r641343393
>
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java line 40:
> 
>> 38:  * @requires vm.cds.custom.loaders
>> 39:  * @summary Test class loader constraint checks for archived classes with custom class loader
>> 40:  * @bug 8267347
> 
> You've omitted the 8267754 bug id. Please also add the current bug id.

I think the bug IDs should only include the product bugs that we are testing to test. The current bug (8267958) and 8267754 are both bugs in this test itself, so including them here isn't very useful.

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

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

From dholmes at openjdk.java.net  Tue Jun  1 23:39:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 23:39:07 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v5]
In-Reply-To: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
Message-ID: <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>

> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
> 
> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
> 
> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
> 
> Testing: tiers 1-3, plus the new test
> 
> Thanks,
> David

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

 - Merge branch 'master' into 8267118-oome
 - Simplified logging to reuse Info statements as suggested by @coleenp
 - Fix mh() usage
 - Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
   feedback from @coleenp @iklam
 - Merge branch 'master' into 8267118-oome
 - 8267118: OutOfMemoryError cannot be caught as a Throwable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4266/files
  - new: https://git.openjdk.java.net/jdk/pull/4266/files/ce8496bd..9732c43b

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

  Stats: 24818 lines in 857 files changed: 4076 ins; 19201 del; 1541 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4266/head:pull/4266

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

From jiefu at openjdk.java.net  Wed Jun  2 00:06:29 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 00:06:29 GMT
Subject: RFR: 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java
 timed out
In-Reply-To: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
References: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
Message-ID: <UV8y55itJi4kxc_g3XOk_M6ZsUlc7eX21inSDYvBJc4=.65d28fa0-4a0d-4c54-b6c5-e11f8a32b169@github.com>

On Tue, 1 Jun 2021 19:35:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [JDK-8267347](https://bugs.openjdk.java.net/browse/JDK-8267347) doubles the amount of time spent inside this test. It's better to split the test into two parts as suggested by @iignatev in https://github.com/openjdk/jdk/pull/4198#discussion_r641343393

This makes sense and it passed on x86_32.
Thanks.

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

Marked as reviewed by jiefu (Reviewer).

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

From jiefu at openjdk.java.net  Wed Jun  2 00:41:59 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 00:41:59 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v3]
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <KKZKXBZxQx-o9JKKJcTLaXr1aNmNtTyPhi3iYRocrxc=.8489c5fb-a4b8-4d80-ab17-b6ef7d4152ed@github.com>

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

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

  Simplify the fix for s390

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4277/files
  - new: https://git.openjdk.java.net/jdk/pull/4277/files/e7c7d565..41f6cc18

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

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

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

From jiefu at openjdk.java.net  Wed Jun  2 00:41:59 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 00:41:59 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v2]
In-Reply-To: <jL3gX6A4HU3GM-uNhjAhZGuk_Nd2EDM14-o2Qx7Bz2I=.0a363066-b17d-4dc0-873e-bacd28edee92@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <9VmUd6Rs8-4P992tRVdh6t8LEjPXRC1NEZwCeoxV88E=.7cba3430-3f9a-4338-b9f1-0673591cfe21@github.com>
 <jL3gX6A4HU3GM-uNhjAhZGuk_Nd2EDM14-o2Qx7Bz2I=.0a363066-b17d-4dc0-873e-bacd28edee92@github.com>
Message-ID: <105FmhE-cv7gnG8oQj3DCL_XwbcokUDUvSryGzKl-GM=.f9607124-42dc-4a87-ba98-fd1f24755513@github.com>

On Tue, 1 Jun 2021 23:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would prefer to only use what we need to fix the problem on the "old" system that it was observed rather than trying to generalize this for arbitrary/unknown old versions of Linux. Otherwise we can never know when it is okay to remove this code.
> 
> David

Updated.
Seems more clear now.
Thanks.

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

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

From lmesnik at openjdk.java.net  Wed Jun  2 01:20:48 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 2 Jun 2021 01:20:48 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

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

  strdup_check_oom is used instead of strdup.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4292/files
  - new: https://git.openjdk.java.net/jdk/pull/4292/files/e1542ddb..15572433

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

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

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

From lmesnik at openjdk.java.net  Wed Jun  2 01:20:48 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 2 Jun 2021 01:20:48 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <fgaB_Gl-1k_7HzlwUYLAo7YnZGOsAZ_AuadthiFEd9Q=.3affbd24-77fc-4451-9b01-2f134192ceee@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

Serguei, 

Thanks for the suggestion. It is not exactly part of this bug but is really close. Updated to used strdup_check_oom  instead of strdup.

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

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

From coleenp at openjdk.java.net  Wed Jun  2 01:47:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 2 Jun 2021 01:47:34 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v5]
In-Reply-To: <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>
Message-ID: <zrd8a9KV0PmV6jzXgJjuh3YnTtl1SoLSLgI4FSWU2rQ=.b1477703-128c-4a73-9682-eb0be007d219@github.com>

On Tue, 1 Jun 2021 23:39:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>> 
>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>> 
>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>> 
>> Testing: tiers 1-3, plus the new test
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8267118-oome
>  - Simplified logging to reuse Info statements as suggested by @coleenp
>  - Fix mh() usage
>  - Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>    feedback from @coleenp @iklam
>  - Merge branch 'master' into 8267118-oome
>  - 8267118: OutOfMemoryError cannot be caught as a Throwable

Thanks for making the changes.  It looks good!  Thank you for fixing this.

src/hotspot/share/oops/method.cpp line 263:

> 261:         return handler_bci;
> 262:       } else if (ex_klass == NULL) {
> 263:         // Is this even possible?

Good question. this seems odd - there should always be a klass.  Maybe investigate as a follow up.

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

Marked as reviewed by coleenp (Reviewer).

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

From coleenp at openjdk.java.net  Wed Jun  2 01:47:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 2 Jun 2021 01:47:34 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v3]
In-Reply-To: <8PPeXX_Zb5hLbudIbarOsqjbjyie6GI939HUj8ep3LE=.8845b3a4-2547-46e1-af90-206ba0c37995@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <TwN_Kb3ouKWf9UnbE0njTYZzVe1Qig8D44CCI81tMJo=.e8665299-c61f-4ff0-9680-88199586d643@github.com>
 <K_76yeHXW0IfEUFS60E2RSK0yKwWED5rop_Pl8QShLQ=.8fc66a8e-6170-499c-873b-50792b70816b@github.com>
 <8PPeXX_Zb5hLbudIbarOsqjbjyie6GI939HUj8ep3LE=.8845b3a4-2547-46e1-af90-206ba0c37995@github.com>
Message-ID: <6jrSkgOrvrH9KgkEFE_YirGeVGjMLK3gjCJ41MMc-0Y=.0980ad58-d1e1-477b-bd80-24ae0c53cf93@github.com>

On Tue, 1 Jun 2021 23:26:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/Throwable/TestCatchThrowableOOM.java line 29:
>> 
>>> 27:  * @summary Test catching Throwable doesn't trigger OOME
>>> 28:  * @library /test/lib
>>> 29:  * @run driver TestCatchThrowableOOM
>> 
>> Do you  want to run this with -Xlog:exceptions=debug to verify that the debug statements print.  I don't think you should verify them if you don't want to but make sure that the code is exercised going forward.
>
> The test itself doesn't need logging, the exec'd VM has all the logging enabled.

ok.

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

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

From david.holmes at oracle.com  Wed Jun  2 02:09:51 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Jun 2021 12:09:51 +1000
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v5]
In-Reply-To: <zrd8a9KV0PmV6jzXgJjuh3YnTtl1SoLSLgI4FSWU2rQ=.b1477703-128c-4a73-9682-eb0be007d219@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>
 <zrd8a9KV0PmV6jzXgJjuh3YnTtl1SoLSLgI4FSWU2rQ=.b1477703-128c-4a73-9682-eb0be007d219@github.com>
Message-ID: <8052fdbc-d86d-0f78-4200-e2cb29c2f14e@oracle.com>

On 2/06/2021 11:47 am, Coleen Phillimore wrote:
> On Tue, 1 Jun 2021 23:39:07 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>>>
>>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>>>
>>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>>>
>>> Testing: tiers 1-3, plus the new test
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>>
>>   - Merge branch 'master' into 8267118-oome
>>   - Simplified logging to reuse Info statements as suggested by @coleenp
>>   - Fix mh() usage
>>   - Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>>     feedback from @coleenp @iklam
>>   - Merge branch 'master' into 8267118-oome
>>   - 8267118: OutOfMemoryError cannot be caught as a Throwable
> 
> Thanks for making the changes.  It looks good!  Thank you for fixing this.

Thanks for the review Coleen!

> src/hotspot/share/oops/method.cpp line 263:
> 
>> 261:         return handler_bci;
>> 262:       } else if (ex_klass == NULL) {
>> 263:         // Is this even possible?
> 
> Good question. this seems odd - there should always be a klass.  Maybe investigate as a follow up.

I'm not sure if this is just the code being "robust" or not. I tried 
tracking back to see if a NULL could sneak in anywhere but the code 
paths get complicated on the JVM TI side.

Thanks,
David

> -------------
> 
> Marked as reviewed by coleenp (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4266
> 

From dholmes at openjdk.java.net  Wed Jun  2 02:30:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 02:30:47 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
Message-ID: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>

>From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:

http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html

Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.

Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).

So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.

I will also run benchmarks to watch for issues with the unicode conversion costs related to this.

The logging strategy is as follows:
- info: show whether the new API is available or not
- debug: report failures that are ignored (as we fallback to debugger mechanism)
- trace: report successes for full tracking

Testing:
  - internal self-verification in debug builds as previously described
 - verified the logging output on different Windows systems that have, and don't have, the new API
 - sanity testing for tiers 1-3

Thanks,
David

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

Commit messages:
 - Should the logging output in the test log so we can check its contents even when it passes.
 - 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name

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

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

From dholmes at openjdk.java.net  Wed Jun  2 02:59:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 02:59:34 GMT
Subject: RFR: 8267879: ClassLoaderMetaspace destructor asserts on !_frozen
In-Reply-To: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
References: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
Message-ID: <Ps0yClp3sYJxgvGazEVIyNKkBz-jUPgouKEH-2kvNqc=.09a49005-5657-41d2-8c8f-3827baa5e27c@github.com>

On Tue, 1 Jun 2021 18:30:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Summary: The assert was a false negative. `Metaspace::freeze()` is obsolete and should be removed.
> 
> The original reason for the `Metaspace::freeze()` API was to ensure that the safepoint portion of -Xshare:dump, i.e., `VM_PopulateDumpSharedSpace::doit()` does not call `Metaspace::allocate()`, which might cause a GC, resulting in  a deadlock.
> 
> However, since [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149), GC would happen only with the `TRAPS` version of `Metaspace::allocate()`. Since [JDK-8252685](https://bugs.openjdk.java.net/browse/JDK-8252685), `TRAPS` must be a `JavaThread`. This means that you can no longer cause a GC inside safepoint code by calling `Metaspace::allocate()`.
> 
> `Metaspace::assert_not_frozen()` was also called by the `ClassLoaderMetaspace` allocation/deallocation functions, but none of these would cause GC. Also, anyone calling these function while a safepoint is in progress (such as the ZGC code that triggered this assert) must ensure that they won't affect any code that concurrently traverses metaspace objects inside the safepoint. Such safeguard logic is already done at a higher level, we don't need the low-level asserts inside  the `ClassLoaderMetaspace` allocation/deallocation functions.

Hi Ioi,

Thanks for the detailed explanation. This seems fine.

David

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

Marked as reviewed by dholmes (Reviewer).

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

From david.holmes at oracle.com  Wed Jun  2 03:02:51 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Jun 2021 13:02:51 +1000
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <FHMp7SXlW_iN-CiE7-azdwlxqCm6px3Zc9OiZyJW-eU=.2c84e7ea-d492-42ef-91e1-3bed781ee0b7@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <FHMp7SXlW_iN-CiE7-azdwlxqCm6px3Zc9OiZyJW-eU=.2c84e7ea-d492-42ef-91e1-3bed781ee0b7@github.com>
Message-ID: <769b1c12-ab75-244b-1922-6c73618260d8@oracle.com>

On 2/06/2021 2:01 am, Daniel D.Daugherty wrote:
> On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> The root cause of the intermittent failure is that _decorators in LogDecorations
>>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>>> Log output via set_log_config(TestLogFileName, "all=off").
>>>
>>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well.
>>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>>>
>>> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
>>> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated.
>>> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.
>>
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Increase reader's counter before creating LogDecoration.
> 
> It looks like this failure is taking a bit of work to resolve. I've gone ahead and
> ProblemListed the test. At this point we have 20 sightings in Tier[3-7]. Since
> this failure is intermittent, I would want to see Tier[5-7] testing done before
> the fix is integrated.

I've submitted the basic fix for tiers 5-7 testing.

Xin: note you will need to merge with master and remove the test from 
the Problem-list again as part of this PR.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4257
> 

From dholmes at openjdk.java.net  Wed Jun  2 04:11:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 04:11:31 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v3]
In-Reply-To: <KKZKXBZxQx-o9JKKJcTLaXr1aNmNtTyPhi3iYRocrxc=.8489c5fb-a4b8-4d80-ab17-b6ef7d4152ed@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KKZKXBZxQx-o9JKKJcTLaXr1aNmNtTyPhi3iYRocrxc=.8489c5fb-a4b8-4d80-ab17-b6ef7d4152ed@github.com>
Message-ID: <vPk45y7Vdv1R5wPtpMoUbTJEYCXBS_Yh854KLyLR9Qs=.322ab5df-3e71-405c-934b-4b2e08fbe551@github.com>

On Wed, 2 Jun 2021 00:41:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify the fix for s390

This simple fix, as suggested by @MBaesken, is fine with me, as long as it actually fixes the problem.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From navy.xliu at gmail.com  Wed Jun  2 05:16:07 2021
From: navy.xliu at gmail.com (Liu Xin)
Date: Tue, 1 Jun 2021 22:16:07 -0700
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <769b1c12-ab75-244b-1922-6c73618260d8@oracle.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <FHMp7SXlW_iN-CiE7-azdwlxqCm6px3Zc9OiZyJW-eU=.2c84e7ea-d492-42ef-91e1-3bed781ee0b7@github.com>
 <769b1c12-ab75-244b-1922-6c73618260d8@oracle.com>
Message-ID: <CAHPdc0=Aovn0TRETRtQ8KFVo_hpTXrCmS7XNJs_tV6jpKbwWTg@mail.gmail.com>

hi, David,

Thanks.  Let's see the results of tier5~7 with the basic fix.  If it can
pass all tests, it means that it's wrong to hoist AsyncLogWriter::flush().

Actually, I didn't change a lot in this PR. I hoisted the
AsyncLogWriter::flush() because in my understanding one flush() can remove
two hazards in async mode.
https://openjdk.github.io/cr/?repo=jdk&pr=4257&range=00-01#udiff-1-src/hotspot/share/logging/logConfiguration.cpp

Yesterday, when you ran the tier3~4 test, did all failures occur on aarch64?
If so, my only explanation is that this code may not be safe on aarch64.
That doesn't make sense because OrderAccess::storeload() is a full memory
barrier on aarch64.

void LogOutputList::wait_until_no_readers() const {
  OrderAccess::storeload();
  while (_active_readers != 0) {
    // Busy wait
  }
}

So far, I still can't reproduce the crash you sent me yesterday on aarch64.
I tried different configurations and even used cset to simulate different
numbers of cores.







On Tue, Jun 1, 2021 at 8:03 PM David Holmes <david.holmes at oracle.com> wrote:

> On 2/06/2021 2:01 am, Daniel D.Daugherty wrote:
> > On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org> wrote:
> >
> >>> The root cause of the intermittent failure is that _decorators in
> LogDecorations
> >>> may be inconsistent with LogOutput::_decorators. It could happen when
> gtest disables a
> >>> Log output via set_log_config(TestLogFileName, "all=off").
> >>>
> >>> Since we copy the entire logDecorations, it's reasonable to copy
> _decorator as well.
> >>> LogDecorator is a bitmask of uint. It's even smaller than a reference
> on LP64 platforms.
> >>>
> >>> This patch not only fixes intermittent crash in JDK-8267926, but also
> fixes JDK-8267952.
> >>> Two hazards of async logging in `LogConfiguration::configure_output`
> are eliminated.
> >>> This patch also adds a storestore barrier to make sure it's safe on
> weak consistency machines.
> >>
> >> Xin Liu has updated the pull request incrementally with one additional
> commit since the last revision:
> >>
> >>    Increase reader's counter before creating LogDecoration.
> >
> > It looks like this failure is taking a bit of work to resolve. I've gone
> ahead and
> > ProblemListed the test. At this point we have 20 sightings in Tier[3-7].
> Since
> > this failure is intermittent, I would want to see Tier[5-7] testing done
> before
> > the fix is integrated.
>
> I've submitted the basic fix for tiers 5-7 testing.
>
> Xin: note you will need to merge with master and remove the test from
> the Problem-list again as part of this PR.
>
> Thanks,
> David
> -----
>
> > -------------
> >
> > PR: https://git.openjdk.java.net/jdk/pull/4257
> >
>

From rehn at openjdk.java.net  Wed Jun  2 06:37:32 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 06:37:32 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
Message-ID: <ZqYFohZWTCts1ptJtukUr-oICAMgQrakS3NIBSYIUOE=.f6d81b83-7309-4bb9-9d06-c7b85b4dce68@github.com>

On Tue, 1 Jun 2021 19:20:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi Robbin,
> 
> I think your patch looks good and fixes the issue with is_locked().
> Based on the root cause it seems another simpler solution would have been to add a fence between claim_handshake() and can_process_handshake() to make sure the target sees the write to _owner before we read a handshake safe state. If the issue is that _owner should be only use for debug builds or that the fence should have been in Mutex class and we don't want to affect all other cases, then we could use _active_handshaker instead of _owner. That way we could also keep the while loop in try_process() to process multiple operations at a time, and don't worry about the peek vs pop issue.
> 
> Thanks,
> Patricio

Thanks for having a look.

The main reason for not just adding the fence or use another state is that it leaves us with three different variables.
Since keeping track of three states, poll, queue and owner turn out to be a handful, reducing it back to two states I hope we can easier reason about the code.
Thus having queue non-empty (which was also suggested instead of using is_locked when it was introduced) while executing is the simplest model (but a bigger change).
This also mirrors safepoints: poll, global flag => wait barrier
With                                     : poll, queue => HandshakeState lock

Since there is no performance benefit of looping, except in some test which do millions of them in a few seconds.
If we need looping when removing the executed OP, returning if the op was removed with CAS on _first with NULL we must abort loop, otherwise we can continue.

But removing the looping also simplifies the model and removes many scenarios which no longer needs to reason about.
Again this bug shows that we should simplify, so more people can reason about if this is correct or not.

Thanks Robbin

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

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

From iklam at openjdk.java.net  Wed Jun  2 06:40:36 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Jun 2021 06:40:36 GMT
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v5]
In-Reply-To: <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>
Message-ID: <9NoN4wbNf_toZR7z-6JRqvTTB7wkZE4WSZATDow2stc=.639be04f-5c3c-4a67-828e-4cff24ca5d4b@github.com>

On Tue, 1 Jun 2021 23:39:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>> 
>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>> 
>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>> 
>> Testing: tiers 1-3, plus the new test
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8267118-oome
>  - Simplified logging to reuse Info statements as suggested by @coleenp
>  - Fix mh() usage
>  - Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>    feedback from @coleenp @iklam
>  - Merge branch 'master' into 8267118-oome
>  - 8267118: OutOfMemoryError cannot be caught as a Throwable

Latest version LGTM.

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

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

From mbaesken at openjdk.java.net  Wed Jun  2 06:57:31 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 2 Jun 2021 06:57:31 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <v4UmJdg_ij2nQ8I9LOaz_bYGHIX_AciFDKTM5OTLBJY=.22936ad6-a1ca-4eb8-a796-bd3045e036ce@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
 <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
 <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>
 <v4UmJdg_ij2nQ8I9LOaz_bYGHIX_AciFDKTM5OTLBJY=.22936ad6-a1ca-4eb8-a796-bd3045e036ce@github.com>
Message-ID: <Nxp0-fB4X9ksQARM3Oj9ypA2gpSr_k3q9kLMKzxJsb0=.84c24b91-a0ed-4114-a24f-397f4674c317@github.com>

On Tue, 1 Jun 2021 23:02:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > Hi, checking for the existance of SYS_get_mempolicy AND __NR_get_mempolicy is better.
> 
> So are you fine with the latest change?
> Thanks.

hi, I checked with the larger fix you proposed yesterday. This fixed the night build.

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

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

From jiefu at openjdk.java.net  Wed Jun  2 07:03:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 07:03:41 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <Nxp0-fB4X9ksQARM3Oj9ypA2gpSr_k3q9kLMKzxJsb0=.84c24b91-a0ed-4114-a24f-397f4674c317@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
 <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
 <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>
 <v4UmJdg_ij2nQ8I9LOaz_bYGHIX_AciFDKTM5OTLBJY=.22936ad6-a1ca-4eb8-a796-bd3045e036ce@github.com>
 <Nxp0-fB4X9ksQARM3Oj9ypA2gpSr_k3q9kLMKzxJsb0=.84c24b91-a0ed-4114-a24f-397f4674c317@github.com>
Message-ID: <Pvf5Cg0GvUkQ9l7dzkHsnZQxwqkdXtcQOwIjwHp5zhI=.5ad33c78-35d6-41fb-afeb-660f195ef052@github.com>

On Wed, 2 Jun 2021 06:54:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> hi, I checked with the larger fix you proposed yesterday. This fixed the night build.

Thanks @MBaesken .
If you're fine with the latest version, could please also test it on your s390 machines?
Thanks.

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

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

From xliu at openjdk.java.net  Wed Jun  2 07:06:59 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 2 Jun 2021 07:06:59 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v4]
In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
Message-ID: <mdMyJQjd-U8n7mKaTNjgV7qWOrOtxVL9CsVyGXSjx_U=.db3bd637-9a22-4492-b738-ad696f1986cb@github.com>

> The root cause of the intermittent failure is that _decorators in LogDecorations 
> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
> Log output via set_log_config(TestLogFileName, "all=off").
> 
> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
> 
> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.

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

 - resume gtest/AsyncLogGtest.java
 - Merge branch 'master' into JDK-8267926
 - Add another regression test.
 - Increase reader's counter before creating LogDecoration.
 - 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation.
 - 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4257/files
  - new: https://git.openjdk.java.net/jdk/pull/4257/files/3b2d7636..9632e705

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

  Stats: 27659 lines in 947 files changed: 5648 ins; 19995 del; 2016 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257

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

From alanb at openjdk.java.net  Wed Jun  2 08:47:32 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 2 Jun 2021 08:47:32 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <lFmqzTx5LcP9vagq4s5UiQ0FzZv2MBfaaDataMb5o78=.de180ad5-4b00-4ef1-a4f0-bbed2c850f29@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

I think the named pipe scenario needs more discussion. For the more simpler case of overwriting an existing file then opt-in in with an option like `-overwrite` might be clearer than `-rewrite`. It's important that we choose the right name because there are several commands that may need to do the same.

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

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

From rehn at openjdk.java.net  Wed Jun  2 09:23:33 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 09:23:33 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
Message-ID: <jBqg1OTbfHSS1huaLf3XoR0o6gmlFORw32v4QZsfaiw=.0162e40a-a248-4adb-93ae-dfe51a1e9808@github.com>

On Tue, 1 Jun 2021 20:48:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into handshakee
>>  - Small update
>>  - Merge branch 'master' into handshakee
>>  - Fix
>
> src/hotspot/share/runtime/handshake.cpp line 429:
> 
>> 427:   assert(_handshakee == Thread::current(), "Must be called by self");
>> 428:   assert(_lock.owned_by_self(), "Lock must be held");
>> 429:   return _queue.peek();
> 
> `get_op_for_self()` name does not match the `peek()` operation.
> The new name should be `peek_op_for_self()`.

The method retrieves the next operation to be executed, hence 'get'.
That the method uses a queue which provides a pop() and peek() is an implementation, there is no value for the user of  get_op_for_self() to know how this is done?

> src/hotspot/share/runtime/handshake.cpp line 445:
> 
>> 443:   assert(_handshakee != Thread::current(), "Must not be called by self");
>> 444:   assert(_lock.owned_by_self(), "Lock must be held");
>> 445:   return _queue.peek(non_self_queue_filter);
> 
> `get_op()` name does not match the peek() operation.
> The new name should be `peek_op()`.

The method retrieves the next operation to be executed, hence 'get'.
That the method uses a queue which provides a pop() and peek() is an implementation, there is no value for the user of  get_op_for_self() to know how this is done?

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

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

From ysuenaga at openjdk.java.net  Wed Jun  2 09:32:33 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 2 Jun 2021 09:32:33 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage inside a
 container
Message-ID: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>

jdk.CPULoad event reports CPU usage.
If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.

When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.


public class InfiniteLoop{
  public static void main(String[] args){
    while(true){
    }
  }
}


jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.

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

Commit messages:
 - 8268098: jdk.CPULoad event reports incorrect CPU usage inside a container

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

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

From rehn at openjdk.java.net  Wed Jun  2 09:55:48 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 09:55:48 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
Message-ID: <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>

On Tue, 1 Jun 2021 20:37:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/handshake.cpp line 330:
>> 
>>> 328:   // closure are visible to the VMThread/Handshaker after it reads
>>> 329:   // that the operation has completed.
>>> 330:   Atomic::dec(&_pending_threads);
>> 
>> Why do we need a full fence instead of a release as before?
>
> And does the comment on L326 now need to be updated?

We have three options here:
1: "If the handshake operation is not completed it must be on at least one queue."
2: "If the handshake operation is completed it is not on any queue."
3: "It may be on queue while completed and may not be queue when not completed, it depends."

With the polling mechanism saying you must stop while the queue is not empty, the operation is removed after it is executed, option 1 seemed preferable to me.
Specially if we want a simpler easier model to avoid any further such bugs as this.

This means removal from queue happens after decrement of _pending_threads.
remove_op() -> pop() gives no ordering guarantee, those comes from the mutex.

The technical note on the current implementation of the queue is:
Only first can be read without lock and the implementation of first manipulation is done with a CAS.
So a side-effect of current implementation is that the only thing that can be seen will be ordered.

Since we running in slowpath there is no need to reduce ordering to a minimum and we can thus change the queue implementation since it have no guarantees to do any ordering without worrying about someone (ab)using side-effects.

Do you agree?

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

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

From dholmes at openjdk.java.net  Wed Jun  2 10:31:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:31:28 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <BZUzA_wBLI7AjaxxFiteGR1jVnUJSrcBifaF6H32B-g=.9e1d1cac-91cd-46a6-b8e9-97d7f99cd305@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

I've checked the performance impact and there are no regressions across a set of sanity footprint and performance benchmarks in product mode.

For fastdebug there is a very slight regression in footprint, but that seems likely to be a false result and is not important for fastdebug anyway.

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

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

From dholmes at openjdk.java.net  Wed Jun  2 10:32:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:32:41 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
Message-ID: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>

Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).

Affected tests:

- vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/

This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.

Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.

- vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
- vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java

These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.

Testing:
 - local testing of affected test areas
 - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).

Thanks,
David

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

Commit messages:
 - 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes

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

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

From vlivanov at openjdk.java.net  Wed Jun  2 10:32:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 2 Jun 2021 10:32:41 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
Message-ID: <XSppKMXvVgP-BYpRdvICJ-xbpgUxkgBwuMFaMouiJTs=.6aff87bd-1825-4cd3-a331-74e8efecb144@github.com>

On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
> 
> Affected tests:
> 
> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
> 
> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
> 
> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
> 
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
> 
> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
> 
> Testing:
>  - local testing of affected test areas
>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
> 
> Thanks,
> David

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From dholmes at openjdk.java.net  Wed Jun  2 10:32:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:32:41 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <XSppKMXvVgP-BYpRdvICJ-xbpgUxkgBwuMFaMouiJTs=.6aff87bd-1825-4cd3-a331-74e8efecb144@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
 <XSppKMXvVgP-BYpRdvICJ-xbpgUxkgBwuMFaMouiJTs=.6aff87bd-1825-4cd3-a331-74e8efecb144@github.com>
Message-ID: <J7y3ksx78rNYKIP0BvKKkl96bULnGXSTJp8Kg5vQJH4=.9cd051c5-9d3b-42bf-892a-6d074e4ea523@github.com>

On Wed, 2 Jun 2021 10:25:38 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
>> 
>> Affected tests:
>> 
>> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
>> 
>> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
>> 
>> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
>> 
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
>> 
>> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
>> 
>> Testing:
>>  - local testing of affected test areas
>>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
>> 
>> Thanks,
>> David
>
> Looks good.

Thanks @iwanowww !

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

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

From david.holmes at oracle.com  Wed Jun  2 10:39:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Jun 2021 20:39:58 +1000
Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable
 [v5]
In-Reply-To: <9NoN4wbNf_toZR7z-6JRqvTTB7wkZE4WSZATDow2stc=.639be04f-5c3c-4a67-828e-4cff24ca5d4b@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
 <tnYsV-3sN0tUbs_TKZVJXaViMDwwXu2K_pMslF3ZdL8=.ee0388a5-71c7-462e-aa6f-62df53c39139@github.com>
 <9NoN4wbNf_toZR7z-6JRqvTTB7wkZE4WSZATDow2stc=.639be04f-5c3c-4a67-828e-4cff24ca5d4b@github.com>
Message-ID: <ab6a0067-172e-c4ed-a539-58bda385b225@oracle.com>

On 2/06/2021 4:40 pm, Ioi Lam wrote:
> On Tue, 1 Jun 2021 23:39:07 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
>>>
>>> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
>>>
>>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
>>>
>>> Testing: tiers 1-3, plus the new test
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>>
>>   - Merge branch 'master' into 8267118-oome
>>   - Simplified logging to reuse Info statements as suggested by @coleenp
>>   - Fix mh() usage
>>   - Reworked the new logging to seperate Info and Debug levels to reduce verbosity, per
>>     feedback from @coleenp @iklam
>>   - Merge branch 'master' into 8267118-oome
>>   - 8267118: OutOfMemoryError cannot be caught as a Throwable
> 
> Latest version LGTM.

Thanks Ioi!

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4266
> 

From rehn at openjdk.java.net  Wed Jun  2 10:39:29 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 10:39:29 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
Message-ID: <lSv1o3Qj30ojQWAKticWuM_Kb6QGTz_DzfvM1w034H8=.e2f80e5e-4688-49c6-9c72-eedce150af83@github.com>

On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
> 
> Affected tests:
> 
> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
> 
> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
> 
> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
> 
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
> 
> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
> 
> Testing:
>  - local testing of affected test areas
>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
> 
> Thanks,
> David

Seems good!

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

Marked as reviewed by rehn (Reviewer).

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

From david.holmes at oracle.com  Wed Jun  2 10:45:22 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Jun 2021 20:45:22 +1000
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <lSv1o3Qj30ojQWAKticWuM_Kb6QGTz_DzfvM1w034H8=.e2f80e5e-4688-49c6-9c72-eedce150af83@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
 <lSv1o3Qj30ojQWAKticWuM_Kb6QGTz_DzfvM1w034H8=.e2f80e5e-4688-49c6-9c72-eedce150af83@github.com>
Message-ID: <ce6c35b0-bb27-a0c8-68d6-98a7e3d3ecac@oracle.com>

On 2/06/2021 8:39 pm, Robbin Ehn wrote:
> On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
>>
>> Affected tests:
>>
>> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
>>
>> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
>>
>> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
>>
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
>>
>> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
>>
>> Testing:
>>   - local testing of affected test areas
>>   - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
>>
>> Thanks,
>> David
> 
> Seems good!

Thanks Robbin!

David

> -------------
> 
> Marked as reviewed by rehn (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4302
> 

From dholmes at openjdk.java.net  Wed Jun  2 10:45:38 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:45:38 GMT
Subject: Integrated: 8267118: OutOfMemoryError cannot be caught as a Throwable
In-Reply-To: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
References: <EyFy8l89oIuL3pLdYkstsQYQTmI3FdbLnWSuhMLZcfI=.9ce91074-ee8e-4815-8307-1e0f8acfac19@github.com>
Message-ID: <icOEixndNAsjdNtejye-J0elC-69g6GYfHsySOeBTTM=.398e1e24-eb68-4002-8c98-264cd97fa63e@github.com>

On Mon, 31 May 2021 04:43:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block!
> 
> The fix is to force resolution of the catch-type at verification time, when it is Throwable.
> 
> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue.
> 
> Testing: tiers 1-3, plus the new test
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 71425ddf
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71425ddfb4a7cc9e2d1c7c12cfac61c4d9d7fdf4
Stats:     125 lines in 3 files changed: 124 ins; 0 del; 1 mod

8267118: OutOfMemoryError cannot be caught as a Throwable

Co-authored-by: Ioi Lam <iklam at openjdk.org>
Reviewed-by: coleenp

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

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

From mbaesken at openjdk.java.net  Wed Jun  2 11:00:33 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 2 Jun 2021 11:00:33 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <Pvf5Cg0GvUkQ9l7dzkHsnZQxwqkdXtcQOwIjwHp5zhI=.5ad33c78-35d6-41fb-afeb-660f195ef052@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
 <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
 <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>
 <v4UmJdg_ij2nQ8I9LOaz_bYGHIX_AciFDKTM5OTLBJY=.22936ad6-a1ca-4eb8-a796-bd3045e036ce@github.com>
 <Nxp0-fB4X9ksQARM3Oj9ypA2gpSr_k3q9kLMKzxJsb0=.84c24b91-a0ed-4114-a24f-397f4674c317@github.com>
 <Pvf5Cg0GvUkQ9l7dzkHsnZQxwqkdXtcQOwIjwHp5zhI=.5ad33c78-35d6-41fb-afeb-660f195ef052@github.com>
Message-ID: <z631ainzEQpWDwkALxZcCbsos6tfemkNb-j__yrugMU=.de119a45-f41c-4018-b0ed-52eea47dde09@github.com>

On Wed, 2 Jun 2021 07:00:53 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > hi, I checked with the larger fix you proposed yesterday. This fixed the night build.
> 
> Thanks @MBaesken .
> If you're fine with the latest version, could please also test it on your s390 machines?
> Thanks.

Unfortunately, the latest (short) version  fails with 
src/hotspot/os/linux/os_linux.cpp:2966:27: error: '__NR_get_mempolicy' was not declared in this scope
 #define SYS_get_mempolicy __NR_get_mempolicy
                           ^~~~~~~~~~~~~~~~~~

While __NR_get_mempolicy is on the machine in the system headers; it is not picked up, too bad.
Not sure what to include in this case ...

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

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

From rehn at openjdk.java.net  Wed Jun  2 11:13:32 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 11:13:32 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
Message-ID: <ATOV7BbmW63zqPBdh3Y7GohPA9l1sOtTRjzfkSCbUYA=.4ee54ab8-b601-474e-b6b5-be800a275e62@github.com>

On Tue, 1 Jun 2021 20:52:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into handshakee
>>  - Small update
>>  - Merge branch 'master' into handshakee
>>  - Fix
>
> src/hotspot/share/runtime/handshake.cpp line 452:
> 
>> 450:   MatchOp mo(op);
>> 451:   HandshakeOperation* ret = _queue.pop(mo);
>> 452:   assert(ret == op, "OP missing from queue");
> 
> Perhaps this for the assert() mesg:
> `  assert(ret == op, "popped op must match requested op.");
> 
> Also, I would name this one `pop_op()` instead of `remove_op()`.

Changed assert.

In the handshake code we need two operation get operation and remove operation.
They happen to be implemented with peek and pop.
So from the user perspective he wants to remove an operation and thus uses the remove method.
Since we do not want any return from this method, renaming it pop and not return anything is just confusing, isn't it?

> src/hotspot/share/runtime/handshake.cpp line 483:
> 
>> 481:         HandleMark hm(_handshakee);
>> 482:         PreserveExceptionMark pem(_handshakee);
>> 483:         op->do_handshake(_handshakee); // acquire, op removed after
> 
> Why `acquire`? Perhaps:
> `// peek and handshake with op; op removed after`

It's mean do_handshake provide acquire thus op is removed after.

> src/hotspot/share/runtime/handshake.cpp line 489:
> 
>> 487:         // The destructor ~PreserveExceptionMark touches the exception oop so it must not be executed,
>> 488:         // since a safepoint may be in-progress when returning from the async handshake.
>> 489:         op->do_handshake(_handshakee); // acquire, op removed after
> 
> Why acquire? Perhaps:
> // peek and handshake with op; op removed after

It's mean do_handshake provide acquire thus op is removed after.

> src/hotspot/share/runtime/handshake.cpp line 583:
> 
>> 581: 
>> 582:   set_active_handshaker(current_thread);
>> 583:   op->do_handshake(_handshakee); // acquire, op removed after
> 
> Why acquire? Perhaps:
> // peek and handshake with op; op removed after

It's mean do_handshake provide acquire thus op is removed after.

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

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

From rehn at openjdk.java.net  Wed Jun  2 11:19:36 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 11:19:36 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
Message-ID: <wtwJCxYO4lltylbYfD1SOnWfXathUAF9F9bjVcAhLUo=.f3e88f4e-8368-4276-8843-0cff45cadb3a@github.com>

On Tue, 1 Jun 2021 21:14:20 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into handshakee
>>  - Small update
>>  - Merge branch 'master' into handshakee
>>  - Fix
>
> src/hotspot/share/runtime/handshake.hpp line 107:
> 
>> 105:   void remove_op(HandshakeOperation* op);
>> 106: 
>> 107:   void set_active_handshaker(Thread* thread) { Atomic::store(&_active_handshaker, thread); }
> 
> Should:
> ```Thread* _active_handshaker;```
> on L89 above be:
> ```Thread* volatile _active_handshaker;```

Yes, you are correct.

The problematic scenario is Deoptimization::deoptimize_frame which is uses this method to figure out how to deopt the frame. In that case _active_handshaker can be concurrently accessed.

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

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

From jiefu at openjdk.java.net  Wed Jun  2 11:28:46 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 11:28:46 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

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

  __NR_get_mempolicy may be also undefined

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4277/files
  - new: https://git.openjdk.java.net/jdk/pull/4277/files/41f6cc18..73f6b8d9

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

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

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

From mbaesken at openjdk.java.net  Wed Jun  2 11:28:47 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 2 Jun 2021 11:28:47 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
Message-ID: <Xn7aturye8zvgVd9WY7YfJzw8HTXa2XmmGXAM3o2ZjI=.dce3b0e6-7c5a-4673-8c86-433840344dfa@github.com>

On Wed, 2 Jun 2021 11:25:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   __NR_get_mempolicy may be also undefined

Marked as reviewed by mbaesken (Reviewer).

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

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

From jiefu at openjdk.java.net  Wed Jun  2 11:28:47 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 11:28:47 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <z631ainzEQpWDwkALxZcCbsos6tfemkNb-j__yrugMU=.de119a45-f41c-4018-b0ed-52eea47dde09@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <PGQT2pHWzajc4Ncnr06RIXGdISrfhmjuPsR63PJkF3M=.070a2abe-aeab-46e9-ad05-518ba82851d1@github.com>
 <9PiivRLE7vuu7e7G9Ni9qeFiloSFpLkZwGY0sUsdVdo=.42852521-c10a-44e2-9f1a-05ba4a439c16@github.com>
 <iazFiDxlE8XozIPNMnFysxe-od5vwmrR0k2gXDjET10=.1098ccbd-f887-4a72-9dee-cdcd682531d6@github.com>
 <JAUvVBws5xYd2WrdMZ3DQJ3k3zVW0pJ2x-ep0yJawb8=.c856a041-6ffe-4686-ab5b-17499f0efcfa@github.com>
 <v4UmJdg_ij2nQ8I9LOaz_bYGHIX_AciFDKTM5OTLBJY=.22936ad6-a1ca-4eb8-a796-bd3045e036ce@github.com>
 <Nxp0-fB4X9ksQARM3Oj9ypA2gpSr_k3q9kLMKzxJsb0=.84c24b91-a0ed-4114-a24f-397f4674c317@github.com>
 <Pvf5Cg0GvUkQ9l7dzkHsnZQxwqkdXtcQOwIjwHp5zhI=.5ad33c78-35d6-41fb-afeb-660f195ef052@github.com>
 <z631ainzEQpWDwkALxZcCbsos6tfemkNb-j__yrugMU=.de119a45-f41c-4018-b0ed-52eea47dde09@github.com>
Message-ID: <vjTSZBMI82FTE8N748f2HStPAemotxvVyWf0UdSgNrY=.2652f82e-e5cf-4a88-9ee5-b3d9e7aacbb4@github.com>

On Wed, 2 Jun 2021 10:57:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > > hi, I checked with the larger fix you proposed yesterday. This fixed the night build.
> > 
> > 
> > Thanks @MBaesken .
> > If you're fine with the latest version, could please also test it on your s390 machines?
> > Thanks.
> 
> Unfortunately, the latest (short) version fails with
> src/hotspot/os/linux/os_linux.cpp:2966:27: error: '__NR_get_mempolicy' was not declared in this scope
> #define SYS_get_mempolicy __NR_get_mempolicy
> ^~~~~~~~~~~~~~~~~~
> 
> While __NR_get_mempolicy is on the machine in the system headers; it is not picked up, too bad.
> Not sure what to include in this case ...

Thanks @MBaesken .

Then, I would prefer the larger one, which had been tested last night.
And patch has been updated.

Or shall we only keep the fix for s390?
What do you think?
Thanks.

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

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

From rehn at openjdk.java.net  Wed Jun  2 11:44:33 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 11:44:33 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
Message-ID: <yAUag-WMEtF9G-C9Z_ps74grsbFDwhmvaevEsKQxVg0=.f6d78a18-b549-4b6d-bebd-1200aba8e167@github.com>

On Tue, 1 Jun 2021 21:18:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into handshakee
>>  - Small update
>>  - Merge branch 'master' into handshakee
>>  - Fix
>
> src/hotspot/share/utilities/filterQueue.inline.hpp line 127:
> 
>> 125:   do {
>> 126:     if (match_func(cur->_data)) {
>> 127:       match = cur;
> 
> Hmmm.... I was expecting a break after this match.
> Is there a reason to continue the loop?
> 
> But now I'm realizing that I'm confused since this is called `peek()`, but
> it's not really peeking at the head of the queue. It is searching the entire
> queue for a match.

It is a FIFO queue, which provides inserts at the end and retrieves at the front of the queue (push/pop/peek).
Push inserts at tail and pop/peek looks at head. (maybe these should be named differently to reflect this better, but that is another PR :) )

To provide lock-free inserts the queue only have a tail pointer.
This enabled us to do concurrent inserts with other inserts and/or another serialized operation, such as peek.
To get to the front of the queue we must always walk until the end.

This means peek is peeking at the head (with a filter).
Conceptually we generate a queue from that filter and from that virtual queue we peek at it's head.

Tail->A1->A2->A3->A4->A5
Filter = even
Virtual tail->A2->A4
Virtutal head = A4

To get to A4 we walk and apply the filter, the last match will be the head we are looking to peek at.

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

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

From rehn at openjdk.java.net  Wed Jun  2 11:50:31 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 11:50:31 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
Message-ID: <F9FVgbX_gS4sOCFerUXUSNT3ecLnchTA-l1FuqFDLws=.255d1b2e-f810-4161-b414-9c897f631964@github.com>

On Tue, 1 Jun 2021 21:27:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I've stopped my review because I realized that I have gotten confused by
> the `peek()` operation that actually appears to be searching for a match
> rather than peeking at the head (or tail) of the queue. My brain is no longer
> clear on what your operations are. Sorry.

Thanks, sorry about that, hopefully something above can clear that out!

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

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

From dholmes at openjdk.java.net  Wed Jun  2 12:23:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 12:23:31 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
Message-ID: <riDpy9I02yZKgjXTNo1S90ub-XAddDVGRU8NfPcwYNY=.f912c62f-87d3-4ed4-aac3-e3d80c55e5c5@github.com>

On Wed, 2 Jun 2021 11:28:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   __NR_get_mempolicy may be also undefined

I would prefer to see something smaller and S390 specific as there is only a problem on that platform.

Also is the right check for S390 or  __s390x__ ? Different versions of this patch have used each of them. I have no idea what the classification of S390 machines is, so ni idea if these are in fact equivalent. ??

Thanks,
David

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

Changes requested by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Wed Jun  2 12:27:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 12:27:31 GMT
Subject: Integrated: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
Message-ID: <Yv61OAQxwgIsPH1IjRuId9wZHaJ4lE5mNOTpEo10AZ4=.07e36f70-bc65-48fa-9b90-d3c7dfadf757@github.com>

On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
> 
> Affected tests:
> 
> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
> 
> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
> 
> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
> 
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
> 
> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
> 
> Testing:
>  - local testing of affected test areas
>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: dc19baca
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dc19baca3363a105a5cc1dbc02cbe3ea65e1209e
Stats:     339 lines in 14 files changed: 0 ins; 326 del; 13 mod

8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes

Reviewed-by: vlivanov, rehn

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

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

From mbaesken at openjdk.java.net  Wed Jun  2 13:16:29 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 2 Jun 2021 13:16:29 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
Message-ID: <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>

On Wed, 2 Jun 2021 11:28:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   __NR_get_mempolicy may be also undefined

> I would prefer to see something smaller and S390 specific as there is only a problem on that platform.
> 
> Also is the right check for S390 or **s390x** ? Different versions of this patch have used each of them. I have no idea what the classification of S390 machines is, so ni idea if these are in fact equivalent. ??
> 
> Thanks,
> David

The  S390 works nicely for both "flavors" it comes from our own autoconf/platform.m4

  elif test "x$OPENJDK_$1_CPU" = xs390; then
    HOTSPOT_$1_CPU_DEFINE=S390
  elif test "x$OPENJDK_$1_CPU" = xs390x; then
    HOTSPOT_$1_CPU_DEFINE=S390

So this looks reliable.   The  other one  `__s390x__`  seems to come from GNUC, see  https://sourceforge.net/p/predef/wiki/Architectures/ . It worked too nicely in our night make.   However I think the HS macro S390 would be prefered in HS coding  (it is used at quite alot of places ).
Regarding a shorter version, then maybe this one (its ugly but should work my colleagues told me the old value 236 for the mempolicy would be recognized too ).

#if !defined(SYS_get_mempolicy) && defined(S390)
// No SYS_get_mempolicy definition on SUSE Linux Enterprise Server 11.4 (s390x)
#define SYS_get_mempolicy 236
#endif

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

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

From mdoerr at openjdk.java.net  Wed Jun  2 13:24:40 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Jun 2021 13:24:40 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
Message-ID: <VaqNloVAfpHSj_d7WHS2WvOzsBBeR0lCaM3eELMtiz4=.f4082fab-e637-43e0-af6a-7cde9182612c@github.com>

On Wed, 2 Jun 2021 11:28:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   __NR_get_mempolicy may be also undefined

Right, `S390` is used in OS independent hotspot code. `__s390x__` comes from the linux headers. So, in os_linux, both macros can get used.
I'm fine with either version, but I'm not sure if only s390 is affected. I haven't heard from people who build zero on other platforms.

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

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

From jiefu at openjdk.java.net  Wed Jun  2 13:33:31 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 13:33:31 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <VaqNloVAfpHSj_d7WHS2WvOzsBBeR0lCaM3eELMtiz4=.f4082fab-e637-43e0-af6a-7cde9182612c@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <VaqNloVAfpHSj_d7WHS2WvOzsBBeR0lCaM3eELMtiz4=.f4082fab-e637-43e0-af6a-7cde9182612c@github.com>
Message-ID: <8iCOG9o26z2kz5OtZK37tr9WxGMGHUmxjtQKl2TX1SA=.f9235636-80d8-4ba7-97a7-37c3a8de75e0@github.com>

On Wed, 2 Jun 2021 13:21:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'm fine with either version, but I'm not sure if only s390 is affected. I haven't heard from people who build zero on other platforms.

I'm also a bit worrying about this.

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

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

From jiefu at openjdk.java.net  Wed Jun  2 13:33:32 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 13:33:32 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>
Message-ID: <Yp4SvKutrerUusNio5bfd5bsV7IpAZ5fkU7iQiyLYRM=.1847365e-265e-46d4-8e46-edced2df5d12@github.com>

On Wed, 2 Jun 2021 13:13:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Regarding a shorter version, then maybe this one (its ugly but should work my colleagues told me the old value 236 for the mempolicy would be recognized too ).

So it sounds really ugly.

What do you think of this fix?

diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp
index e3a7e28..4044b7b 100644
--- a/src/hotspot/os/linux/os_linux.cpp
+++ b/src/hotspot/os/linux/os_linux.cpp
@@ -2963,6 +2963,7 @@ void* os::Linux::libnuma_v2_dlsym(void* handle, const char* name) {
 
 // Check numa dependent syscalls
 static bool numa_syscall_check() {
+#ifdef SYS_get_mempolicy
   // NUMA APIs depend on several syscalls. E.g., get_mempolicy is required for numa_get_membind and
   // numa_get_interleave_mask. But these dependent syscalls can be unsupported for various reasons.
   // Especially in dockers, get_mempolicy is not allowed with the default configuration. So it's necessary
@@ -2972,6 +2973,7 @@ static bool numa_syscall_check() {
   if (syscall(SYS_get_mempolicy, &dummy, NULL, 0, (void*)&dummy, 3) == -1) {
     return false;
   }
+#endif
 
   return true;
 }

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

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

From mdoerr at openjdk.java.net  Wed Jun  2 13:45:31 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Jun 2021 13:45:31 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
Message-ID: <ftnTcnQlHqVi7zkIdU-JKWW6lm_V0qCE_o1llTAaCms=.710ef7b4-7653-4521-824d-6368392d5579@github.com>

On Wed, 2 Jun 2021 11:28:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   __NR_get_mempolicy may be also undefined

Also fine with me. Should we return true or false when SYS_get_mempolicy is not defined?
True would mean not fixing JDK-8241423 on such platforms.
False would basically disable NUMA, but prevent crashes. Right?

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

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

From fweimer at openjdk.java.net  Wed Jun  2 13:56:37 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Wed, 2 Jun 2021 13:56:37 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>
Message-ID: <HjTMSSSiIUG9BcoWJXn1LSsqG3uCONzlFK3yDkfdzps=.16c4c131-f81a-4ea4-bfed-4ea9e3c1802d@github.com>

On Wed, 2 Jun 2021 13:13:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>  `#define SYS_get_mempolicy 236`

This is not the correct number. It is 269 on both s390 and s390x. (236 is `gettid` on s390x.)

The kernel definitions can be a bit difficult to navigate. The glibc sources contain generated lists of system call numbers in the `arch-syscall.h` files (under the `sysdeps/unix/sysv/linux` directory tree), and these numbers are regularly verified on all supported architectures against published kernel sources (using a cross-compiler, so not just some script-based heuristics).

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

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

From rschmelter at openjdk.java.net  Wed Jun  2 14:04:31 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Wed, 2 Jun 2021 14:04:31 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <IZseOR_ScbxJBDrLPS6RodMH2HCFh53MIK0vTZFsqf0=.05f2ac77-15c5-41d0-9933-de1d73e02824@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

I would rename the option to `-overwrite`, since it has a clear meaning (to replace the old content with new one). 

And to really implement the overwrite semantics, the file should be opened with `O_TRUNC`. Currently `-rewrite` just replaces the start of an already existing file with a the heap dump. If the original file was larger than the heap dump, we have trailing bytes, which would lead to errors when tools try to parse the dump. 

And on Unix it might be a good idea to use O_NOCTTY, so we don't accidentally assign a controlling tty when dumping to a console ('ve never seen actual problems omitting this, but it seems safe to add it).

Even with this changes you can still write to a fifo/tty on Unix or a named pipe on Windows, since O_TRUNC is ignored for these types of files.

And since you already created a CSR, I would propose to close [JDK-8263066](https://bugs.openjdk.java.net/browse/JDK-8263066) and instead try to get this into the mainline.

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

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

From jiefu at openjdk.java.net  Wed Jun  2 14:15:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 14:15:33 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <ftnTcnQlHqVi7zkIdU-JKWW6lm_V0qCE_o1llTAaCms=.710ef7b4-7653-4521-824d-6368392d5579@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <ftnTcnQlHqVi7zkIdU-JKWW6lm_V0qCE_o1llTAaCms=.710ef7b4-7653-4521-824d-6368392d5579@github.com>
Message-ID: <-nLtlZIJSVQPSsTqUyZjPRHIt4al_tNNgnJxx_E_hqM=.39ca40d1-c385-4fad-9a1d-dbb23046dcb5@github.com>

On Wed, 2 Jun 2021 13:42:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> False would basically disable NUMA, but prevent crashes. Right?

No.
It would crash only if ZGC is enabled.
So returning true is safe on s390 since there is no zgc on s390 and this is also what the old JDKs (before jdk17) actually do.
Thanks.

> Ok, your proposal is fine. Thanks!

Thanks @TheRealMDoerr .
I'll update it tomorrow if there is no objection.
Thanks.

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

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

From mdoerr at openjdk.java.net  Wed Jun  2 14:15:36 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Jun 2021 14:15:36 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
Message-ID: <L5jEgwRIcA0znHpxyi13VTOplN0nMPh4p3ZraDjmQYI=.90d7599c-e9bb-4b63-a984-30ce84e5989f@github.com>

On Wed, 2 Jun 2021 11:28:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   __NR_get_mempolicy may be also undefined

Ok, your proposal is fine. Thanks!

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

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

From jiefu at openjdk.java.net  Wed Jun  2 14:15:37 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 14:15:37 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <HjTMSSSiIUG9BcoWJXn1LSsqG3uCONzlFK3yDkfdzps=.16c4c131-f81a-4ea4-bfed-4ea9e3c1802d@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>
 <HjTMSSSiIUG9BcoWJXn1LSsqG3uCONzlFK3yDkfdzps=.16c4c131-f81a-4ea4-bfed-4ea9e3c1802d@github.com>
Message-ID: <mtMzHZ5vyhd00iSalcPijHz75Vmu16ghn7zDKkRhWac=.5750824b-a4a6-4090-8e17-59ba50ae3451@github.com>

On Wed, 2 Jun 2021 13:54:04 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> This is not the correct number. It is 269 on both s390 and s390x. (236 is `gettid` on s390x.)

If this is true, there should be a bug in the libnuma source code [1].
All my syscall numbers are copied from libnuma code.
Thanks.

[1] https://github.com/numactl/numactl/blob/master/syscall.c#L121

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

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

From coleenp at openjdk.java.net  Wed Jun  2 15:30:36 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 2 Jun 2021 15:30:36 GMT
Subject: RFR: 8267879: ClassLoaderMetaspace destructor asserts on !_frozen
In-Reply-To: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
References: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
Message-ID: <0YABfOdQ9iyFR3Sgdje_yRAxdwBHYTrwUqTrVJsoD_Y=.78371476-831b-40d9-9529-f164bc3ac3d2@github.com>

On Tue, 1 Jun 2021 18:30:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Summary: The assert was a false negative. `Metaspace::freeze()` is obsolete and should be removed.
> 
> The original reason for the `Metaspace::freeze()` API was to ensure that the safepoint portion of -Xshare:dump, i.e., `VM_PopulateDumpSharedSpace::doit()` does not call `Metaspace::allocate()`, which might cause a GC, resulting in  a deadlock.
> 
> However, since [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149), GC would happen only with the `TRAPS` version of `Metaspace::allocate()`. Since [JDK-8252685](https://bugs.openjdk.java.net/browse/JDK-8252685), `TRAPS` must be a `JavaThread`. This means that you can no longer cause a GC inside safepoint code by calling `Metaspace::allocate()`.
> 
> `Metaspace::assert_not_frozen()` was also called by the `ClassLoaderMetaspace` allocation/deallocation functions, but none of these would cause GC. Also, anyone calling these function while a safepoint is in progress (such as the ZGC code that triggered this assert) must ensure that they won't affect any code that concurrently traverses metaspace objects inside the safepoint. Such safeguard logic is already done at a higher level, we don't need the low-level asserts inside  the `ClassLoaderMetaspace` allocation/deallocation functions.

This is good. I have a question on the conversation.

ZGC is doing concurrent class unloading while CDS is dumping the archive but it must be unloading some hidden class loader and not what CDS is trying to archive, right?

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

Marked as reviewed by coleenp (Reviewer).

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

From pchilanomate at openjdk.java.net  Wed Jun  2 18:13:36 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 2 Jun 2021 18:13:36 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <ZqYFohZWTCts1ptJtukUr-oICAMgQrakS3NIBSYIUOE=.f6d81b83-7309-4bb9-9d06-c7b85b4dce68@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <ZqYFohZWTCts1ptJtukUr-oICAMgQrakS3NIBSYIUOE=.f6d81b83-7309-4bb9-9d06-c7b85b4dce68@github.com>
Message-ID: <-Mca1t6cbBGCTR10rNi6PnebJhw9nu-6nqaH4GGniL4=.511a071e-048c-4f78-838f-d12b96c4fdb6@github.com>

On Wed, 2 Jun 2021 06:34:11 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > Hi Robbin,
> > I think your patch looks good and fixes the issue with is_locked().
> > Based on the root cause it seems another simpler solution would have been to add a fence between claim_handshake() and can_process_handshake() to make sure the target sees the write to _owner before we read a handshake safe state. If the issue is that _owner should be only use for debug builds or that the fence should have been in Mutex class and we don't want to affect all other cases, then we could use _active_handshaker instead of _owner. That way we could also keep the while loop in try_process() to process multiple operations at a time, and don't worry about the peek vs pop issue.
> > Thanks,
> > Patricio
> 
> Thanks for having a look.
> 
> The main reason for not just adding the fence or use another state is that it leaves us with three different variables.
> Since keeping track of three states, poll, queue and owner turn out to be a handful, reducing it back to two states I hope we can easier reason about the code.
> Thus having queue non-empty (which was also suggested instead of using is_locked when it was introduced) while executing is the simplest model (but a bigger change).
> This also mirrors safepoints: poll, global flag => wait barrier
> With : poll, queue => HandshakeState lock
> 
> Since there is no performance benefit of looping, except in some test which do millions of them in a few seconds.
> If we need looping when removing the executed OP, returning if the op was removed with CAS on _first with NULL we must abort loop, otherwise we can continue.
> 
> But removing the looping also simplifies the model and removes many scenarios which no longer needs to reason about.
> Again this bug shows that we should simplify, so more people can reason about if this is correct or not.
> 
> Thanks Robbin

Ok, I see. Yes, the code is now simpler at the expense of a little more overhead (no loop and having to traverse the list twice, one for the get and one for remove). But I guess if in the future we see it's needed we could always add the loop back with the previous approach.

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

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

From pchilanomate at openjdk.java.net  Wed Jun  2 18:13:37 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 2 Jun 2021 18:13:37 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
Message-ID: <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>

On Wed, 2 Jun 2021 09:50:34 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> And does the comment on L326 now need to be updated?
>
> We have three options here:
> 1: "If the handshake operation is not completed it must be on at least one queue."
> 2: "If the handshake operation is completed it is not on any queue."
> 3: "It may be on queue while completed and may not be queue when not completed, it depends."
> 
> With the polling mechanism saying you must stop while the queue is not empty, the operation is removed after it is executed, option 1 seemed preferable to me.
> Specially if we want a simpler easier model to avoid any further such bugs as this.
> 
> This means removal from queue happens after decrement of _pending_threads.
> remove_op() -> pop() gives no ordering guarantee, those comes from the mutex.
> 
> The technical note on the current implementation of the queue is:
> Only first can be read without lock and the implementation of first manipulation is done with a CAS.
> So a side-effect of current implementation is that the only thing that can be seen will be ordered.
> 
> Since we running in slowpath there is no need to reduce ordering to a minimum and we can thus change the queue implementation since it have no guarantees to do any ordering without worrying about someone (ab)using side-effects.
> 
> Do you agree?

Right, but I don't see why the change of just using the queue to check for pending handshakes matters here. This release was to ensure that if the handshakee executed the closure, the memory operations executed in the handshake would be visible to the vmthread/handshaker after seeing the operation was completed (matched with the acquired after is_completed()). What could be the issue if this is not a full fence?

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

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

From iklam at openjdk.java.net  Wed Jun  2 19:02:36 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Jun 2021 19:02:36 GMT
Subject: RFR: 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java
 timed out
In-Reply-To: <UV8y55itJi4kxc_g3XOk_M6ZsUlc7eX21inSDYvBJc4=.65d28fa0-4a0d-4c54-b6c5-e11f8a32b169@github.com>
References: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
 <UV8y55itJi4kxc_g3XOk_M6ZsUlc7eX21inSDYvBJc4=.65d28fa0-4a0d-4c54-b6c5-e11f8a32b169@github.com>
Message-ID: <LwLKzK6We2j-A_o5T47G06CXlqLAC_KxYXI-tDyBCCU=.4c143317-df51-4f37-a4ef-7f80b397ab34@github.com>

On Wed, 2 Jun 2021 00:03:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> [JDK-8267347](https://bugs.openjdk.java.net/browse/JDK-8267347) doubles the amount of time spent inside this test. It's better to split the test into two parts as suggested by @iignatev in https://github.com/openjdk/jdk/pull/4198#discussion_r641343393
>
> This makes sense and it passed on x86_32.
> Thanks.

Thanks @DamonFool and @calvinccheung for the review.

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

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

From iklam at openjdk.java.net  Wed Jun  2 19:09:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Jun 2021 19:09:57 GMT
Subject: Integrated: 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java
 timed out
In-Reply-To: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
References: <eBn4Mz0VIeTHTsXssRRtdTDahra2mWjtNaAaTvvSY-8=.b36e602f-1f1d-46a1-a843-45cd2ec12704@github.com>
Message-ID: <lM0CTRK7BJ3V9xdAhpHpNmgn7IlGWyQ6JPqZ1Er6urM=.e37281e3-6caa-4c1f-a324-a41817926885@github.com>

On Tue, 1 Jun 2021 19:35:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [JDK-8267347](https://bugs.openjdk.java.net/browse/JDK-8267347) doubles the amount of time spent inside this test. It's better to split the test into two parts as suggested by @iignatev in https://github.com/openjdk/jdk/pull/4198#discussion_r641343393

This pull request has now been integrated.

Changeset: ecf6112a
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ecf6112a217e7d5d504a7272111d1ac72745d8f8
Stats:     57 lines in 2 files changed: 40 ins; 11 del; 6 mod

8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java timed out

Reviewed-by: ccheung, jiefu

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

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

From iklam at openjdk.java.net  Wed Jun  2 19:23:41 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Jun 2021 19:23:41 GMT
Subject: RFR: 8267879: ClassLoaderMetaspace destructor asserts on !_frozen
In-Reply-To: <0YABfOdQ9iyFR3Sgdje_yRAxdwBHYTrwUqTrVJsoD_Y=.78371476-831b-40d9-9529-f164bc3ac3d2@github.com>
References: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
 <0YABfOdQ9iyFR3Sgdje_yRAxdwBHYTrwUqTrVJsoD_Y=.78371476-831b-40d9-9529-f164bc3ac3d2@github.com>
Message-ID: <vCWJHK7QQ0Oy7lhWkZfSImVlx2MkAYbMGXoP59aaxLo=.a496e64f-660c-49b7-a6d9-f432ca804214@github.com>

On Wed, 2 Jun 2021 15:27:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ZGC is doing concurrent class unloading while CDS is dumping the archive but it must be unloading some hidden class loader and not what CDS is trying to archive, right?

Yes, ZGC can be unloading non-alive classes while CDS is dumping. I think that's what happened during the crash in this bug report.

Your question led me to finding this bug: [JDK-8268139](https://bugs.openjdk.java.net/browse/JDK-8268139), where CDS could access classes that have been unloaded. I'll try to fix it in JDK 17, too.

Thanks @coleenp and @dholmes-ora for the review.

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

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

From iklam at openjdk.java.net  Wed Jun  2 19:23:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Jun 2021 19:23:42 GMT
Subject: Integrated: 8267879: ClassLoaderMetaspace destructor asserts on
 !_frozen
In-Reply-To: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
References: <3u_M5bSijc-ADH57E-3okSXm_ABp3zB2Nf8bleHOj8Y=.884a1922-161b-4c08-8f55-6622b55674f4@github.com>
Message-ID: <TIJJEm-IyVaW31M_taW15K63nwN-uvJFFKA3x2TfPB8=.ec2f9105-a1b7-49fc-92d1-2481e2977a32@github.com>

On Tue, 1 Jun 2021 18:30:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Summary: The assert was a false negative. `Metaspace::freeze()` is obsolete and should be removed.
> 
> The original reason for the `Metaspace::freeze()` API was to ensure that the safepoint portion of -Xshare:dump, i.e., `VM_PopulateDumpSharedSpace::doit()` does not call `Metaspace::allocate()`, which might cause a GC, resulting in  a deadlock.
> 
> However, since [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149), GC would happen only with the `TRAPS` version of `Metaspace::allocate()`. Since [JDK-8252685](https://bugs.openjdk.java.net/browse/JDK-8252685), `TRAPS` must be a `JavaThread`. This means that you can no longer cause a GC inside safepoint code by calling `Metaspace::allocate()`.
> 
> `Metaspace::assert_not_frozen()` was also called by the `ClassLoaderMetaspace` allocation/deallocation functions, but none of these would cause GC. Also, anyone calling these function while a safepoint is in progress (such as the ZGC code that triggered this assert) must ensure that they won't affect any code that concurrently traverses metaspace objects inside the safepoint. Such safeguard logic is already done at a higher level, we don't need the low-level asserts inside  the `ClassLoaderMetaspace` allocation/deallocation functions.

This pull request has now been integrated.

Changeset: a8835b9c
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a8835b9c08af1438c80144bad7506fb5700511a3
Stats:     24 lines in 4 files changed: 0 ins; 24 del; 0 mod

8267879: ClassLoaderMetaspace destructor asserts on !_frozen

Reviewed-by: dholmes, coleenp

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

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

From mseledtsov at openjdk.java.net  Wed Jun  2 19:58:39 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 2 Jun 2021 19:58:39 GMT
Subject: RFR: 8267917: mark hotspot containers tests which ignore external
 VM flags
In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
Message-ID: <on1kjOXgnuTLcKXQ7-mpyHBLCkuelcLdOPw_e5ntwsM=.21ce5807-2e3e-4929-81bf-15c2cbbbcac7@github.com>

On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags?
> 
> attn: @mseledts
> 
> Cheers,
> -- Igor

Marked as reviewed by mseledtsov (Committer).

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

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

From akozlov at openjdk.java.net  Wed Jun  2 20:05:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Jun 2021 20:05:56 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>

> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
> 
> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
> 
> Reviews of the CSR linked to the bug would be appreciated as well.

Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:

 - Fix create_binary_file
 - Rename option to -overwrite

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4183/files
  - new: https://git.openjdk.java.net/jdk/pull/4183/files/7faa6900..8b97a1e4

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

  Stats: 26 lines in 11 files changed: 0 ins; 8 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183

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

From akozlov at openjdk.java.net  Wed Jun  2 20:51:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Jun 2021 20:51:46 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
Message-ID: <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>

On Wed, 2 Jun 2021 20:05:56 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix create_binary_file
>  - Rename option to -overwrite

I have renamed the option to `-overwrite`. Nice catch about missing O_TRUNC, thanks! A case for the missing O_NOCTTY looks rather special, wouldn't it be a configuration issue?..

SInce JDK-8263066 suggests more enhancements, it may be worth keeping it to track the remaining ones.

@AlanBateman The patch does not do anything special to the named pipe use-case, although makes it possible. Do you suggest removing mentions of the use-case from the CSR? Otherwise, what concerns could I address? 

Thanks!

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

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

From akozlov at openjdk.java.net  Wed Jun  2 20:57:02 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Jun 2021 20:57:02 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>

> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
> 
> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
> 
> Reviews of the CSR linked to the bug would be appreciated as well.

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

  Fix windows flags (although complied fine)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4183/files
  - new: https://git.openjdk.java.net/jdk/pull/4183/files/8b97a1e4..7f19663b

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

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

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

From sspitsyn at openjdk.java.net  Wed Jun  2 21:14:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 2 Jun 2021 21:14:39 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <9iwnQuvgxYP1nJz25GoQDrX-WiNF8BjZwbDJplox470=.1c9e54e7-99f8-4a3e-b470-4c076be1a369@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

Leonid,
I'm not convinced yet it is okay to call strdup_check_oom in this management function.
It'd be nice to check if David agreed with this update.
Thanks,
Serguei

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

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

From iklam at openjdk.java.net  Wed Jun  2 21:50:56 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Jun 2021 21:50:56 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
Message-ID: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>

During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.

The fix:

(1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`

(2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.

Testing -- Mach5 tiers 1-4 in progress

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

Commit messages:
 - 8268139: CDS ArchiveBuilder may reference unloaded classes

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

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

From dcubed at openjdk.java.net  Wed Jun  2 21:56:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 2 Jun 2021 21:56:02 GMT
Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source
Message-ID: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>

A trivial copyright fix.

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

Commit messages:
 - 8268146: fix for JDK-8266254 fails validate-source

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

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

From psandoz at openjdk.java.net  Wed Jun  2 21:56:02 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 2 Jun 2021 21:56:02 GMT
Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source
In-Reply-To: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
References: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
Message-ID: <sEfXAmBnuYTtXe2vLaS3q0BafWyzHGnkCrw-tN9h4gM=.e2242c4a-1b8a-49df-aad7-2cfe17614522@github.com>

On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial copyright fix.

Marked as reviewed by psandoz (Reviewer).

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

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

From dcubed at openjdk.java.net  Wed Jun  2 21:56:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 2 Jun 2021 21:56:03 GMT
Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source
In-Reply-To: <sEfXAmBnuYTtXe2vLaS3q0BafWyzHGnkCrw-tN9h4gM=.e2242c4a-1b8a-49df-aad7-2cfe17614522@github.com>
References: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
 <sEfXAmBnuYTtXe2vLaS3q0BafWyzHGnkCrw-tN9h4gM=.e2242c4a-1b8a-49df-aad7-2cfe17614522@github.com>
Message-ID: <o8oeJXuFF6C5E3w8gXz3ysBu0KXq3yUonGmrXTip68s=.c8bae7fb-3eb6-4402-a44a-7cb6870cb728@github.com>

On Wed, 2 Jun 2021 21:40:59 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> A trivial copyright fix.
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz - Thanks for the fast review!

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

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

From wetmore at openjdk.java.net  Wed Jun  2 21:56:03 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 2 Jun 2021 21:56:03 GMT
Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source
In-Reply-To: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
References: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
Message-ID: <NYKAEyMASMBRjmJuwd-R_UUFv5kKUzsJRTpcCL8U3Ho=.b5616026-412c-4cc7-8dbb-814956f66b29@github.com>

On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial copyright fix.

LGTM

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

Marked as reviewed by wetmore (Reviewer).

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

From dcubed at openjdk.java.net  Wed Jun  2 21:56:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 2 Jun 2021 21:56:03 GMT
Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source
In-Reply-To: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
References: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
Message-ID: <k5qz1kTaVqGmPKDxCoBthc6XEYrsn8Nd4K5LT9XAZt0=.5491de99-f3b8-432e-b263-0e78c5140b4f@github.com>

On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial copyright fix.

This pull request has now been integrated.

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

8268146: fix for JDK-8266254 fails validate-source

Reviewed-by: psandoz, wetmore

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

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

From sspitsyn at openjdk.java.net  Wed Jun  2 21:59:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 2 Jun 2021 21:59:40 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <ZI7hCx8hnnvMMr_e7MYNE4nCEYa21lQ5AK6oq4p6Yjk=.3af22f32-97cc-4170-9511-2675c20a9d84@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

Leonid,
After some thinking, I'm okay with the update.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dcubed at openjdk.java.net  Wed Jun  2 21:59:42 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 2 Jun 2021 21:59:42 GMT
Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source
In-Reply-To: <NYKAEyMASMBRjmJuwd-R_UUFv5kKUzsJRTpcCL8U3Ho=.b5616026-412c-4cc7-8dbb-814956f66b29@github.com>
References: <OxQPCjMBWtaaD9YoMCNVRgFxa-AONvb1iOf0TN0eDWU=.2f639cfc-f13a-4088-9ea1-fbaaaef33cc4@github.com>
 <NYKAEyMASMBRjmJuwd-R_UUFv5kKUzsJRTpcCL8U3Ho=.b5616026-412c-4cc7-8dbb-814956f66b29@github.com>
Message-ID: <8feNIHDZ7xnu8UpIdaM-fZFSd-d90ymV7m0KpoPaeLQ=.6d1236a1-3ad0-49bf-93ef-4c0da97483e7@github.com>

On Wed, 2 Jun 2021 21:50:24 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> A trivial copyright fix.
>
> LGTM

@bradfordwetmore - Thanks for the review.

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

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

From lmesnik at openjdk.java.net  Wed Jun  2 21:59:42 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 2 Jun 2021 21:59:42 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <BYByEnSFCgcVOKJMUmdjMNkpuMMpIOWaeQM6W-OBzu0=.6fa5d37a-3ccd-481e-a486-3c0c0ee6c086@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

I believe that it is safer to use strdup_check_oom anywhere except error handling. The plain strdup might cause delayed SEGV hard to diagnose. Might be it makes sense to file another RFE to review strdup usage.

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

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

From coleenp at openjdk.java.net  Wed Jun  2 22:29:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 2 Jun 2021 22:29:37 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
In-Reply-To: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
Message-ID: <deAKHyi_c_oO70jI_gemQiAsd8LVy6Y5ewOTapUrG_8=.a1c90414-b8f9-4dd7-b823-28ae0f2cd866@github.com>

On Wed, 2 Jun 2021 21:31:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.
> 
> The fix:
> 
> (1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`
> 
> (2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.
> 
> Testing -- Mach5 tiers 1-4 in progress

Except a minor comment, this looks good.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1514:

> 1512:   return k->class_loader_data()->is_alive();
> 1513: }
> 1514: 

There's a k->is_loader_alive() call, so you don't need this.

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

Marked as reviewed by coleenp (Reviewer).

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

From jiefu at openjdk.java.net  Wed Jun  2 23:08:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 23:08:55 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

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

  #ifdef SYS_get_mempolicy in numa_syscall_check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4277/files
  - new: https://git.openjdk.java.net/jdk/pull/4277/files/73f6b8d9..c8f7ce42

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

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

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

From jiefu at openjdk.java.net  Wed Jun  2 23:08:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Jun 2021 23:08:55 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <-nLtlZIJSVQPSsTqUyZjPRHIt4al_tNNgnJxx_E_hqM=.39ca40d1-c385-4fad-9a1d-dbb23046dcb5@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <ftnTcnQlHqVi7zkIdU-JKWW6lm_V0qCE_o1llTAaCms=.710ef7b4-7653-4521-824d-6368392d5579@github.com>
 <-nLtlZIJSVQPSsTqUyZjPRHIt4al_tNNgnJxx_E_hqM=.39ca40d1-c385-4fad-9a1d-dbb23046dcb5@github.com>
Message-ID: <CJt5sstHPce3G3Ead5DdUct1bmsqRUARIQxQHYu_riY=.2df2f8cd-2c4b-4d34-b274-a2f026b0bfca@github.com>

On Wed, 2 Jun 2021 14:12:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > Ok, your proposal is fine. Thanks!
> 
> Thanks @TheRealMDoerr .
> I'll update it tomorrow if there is no objection.
> Thanks.

Updated.
Thanks.

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

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

From iklam at openjdk.java.net  Thu Jun  3 00:07:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 3 Jun 2021 00:07:54 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
 [v2]
In-Reply-To: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
Message-ID: <uQuxUGHlDoprOQXQNoHhfXjX1uUdJdaqasUUSUyNTMo=.8c054395-483d-41d0-90a7-e0f29fa68efe@github.com>

> During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.
> 
> The fix:
> 
> (1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`
> 
> (2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.
> 
> Testing -- Mach5 tiers 1-4 in progress

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

  @coleenp comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4322/files
  - new: https://git.openjdk.java.net/jdk/pull/4322/files/49ae57ae..e624e1f1

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

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

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

From dholmes at openjdk.java.net  Thu Jun  3 00:45:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Jun 2021 00:45:36 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <AaLXtKJLW9gWLbY4_5bsyu3KNrijVi-JEZsmeXefBeU=.9bc702e7-eff5-4fe5-890a-41a85ed52fd5@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

I don't think there is any practical difference between strdup and strdup_check_oom - the chances that we exhaust the C heap just as we hit this call are extremely low, and no matter what we do here the VM is dying if that happens (we may not even have enough memory to call vm_exit_out_of_memory!). The use of strdup_check_oom is at least cleaner as we don't have any issues with not checking the return value from strdup if a static checker looks at this code.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From xliu at openjdk.java.net  Thu Jun  3 01:05:55 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 01:05:55 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v5]
In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
Message-ID: <Pjyi3v7GWOQ3OD50gIToiunSzHVWSYlpHbBSODDAcPQ=.77999a01-fa28-4b31-9911-ce484661da44@github.com>

> The root cause of the intermittent failure is that _decorators in LogDecorations 
> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
> Log output via set_log_config(TestLogFileName, "all=off").
> 
> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
> 
> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.

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

  Hoist assertion earlier.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4257/files
  - new: https://git.openjdk.java.net/jdk/pull/4257/files/9632e705..4184ba51

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

  Stats: 25 lines in 2 files changed: 9 ins; 14 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257

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

From mli at openjdk.java.net  Thu Jun  3 02:04:43 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 3 Jun 2021 02:04:43 GMT
Subject: RFR: JDK-8268018: remove dead code in commitLimitter
Message-ID: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>

it's trivial cleanup to remove some dead code.

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

Commit messages:
 - JDK-8268018: remove dead code in commitLimitter

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

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

From dholmes at openjdk.java.net  Thu Jun  3 02:20:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Jun 2021 02:20:40 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
Message-ID: <dmh2LOhL5ytpVSB2uUGYVurjI_Bo-PAdsjY8E_BN51w=.6fcedb04-3001-43a4-981c-c770957740f2@github.com>

On Wed, 2 Jun 2021 23:08:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   #ifdef SYS_get_mempolicy in numa_syscall_check

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

> 2974:     return false;
> 2975:   }
> 2976: #endif

If SYS_get_mempolicy is not defined then surely this must return false?

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

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

From iklam at openjdk.java.net  Thu Jun  3 02:30:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 3 Jun 2021 02:30:50 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes
Message-ID: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>

This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 

Requested by @rose00 (sorry I took a long time ....).

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

Commit messages:
 - 8248877: Document API contract for MetaspaceObj subtypes

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

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

From dholmes at openjdk.java.net  Thu Jun  3 02:43:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Jun 2021 02:43:36 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
Message-ID: <z3jJxWuQYLCx6glwzvc83Z65F_HmEyGrTJOBhv4R8lA=.cc34c0a6-5475-4e25-882a-c1696a8022d2@github.com>

On Wed, 2 Jun 2021 06:59:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jdk.CPULoad event reports CPU usage.
> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
> 
> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
> 
> 
> public class InfiniteLoop{
>   public static void main(String[] args){
>     while(true){
>     }
>   }
> }
> 
> 
> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.

Hi Yasumasa,

I'm a bit confused. We seem to have this logic in two places  - one in the VM and one in the JDK libraries. Shouldn't this fix look like the fix for JDK-8265836? Can we have just one chunk of code that handles all this?

Thanks,
David

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

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

From jiefu at openjdk.java.net  Thu Jun  3 02:51:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 3 Jun 2021 02:51:33 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <dmh2LOhL5ytpVSB2uUGYVurjI_Bo-PAdsjY8E_BN51w=.6fcedb04-3001-43a4-981c-c770957740f2@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
 <dmh2LOhL5ytpVSB2uUGYVurjI_Bo-PAdsjY8E_BN51w=.6fcedb04-3001-43a4-981c-c770957740f2@github.com>
Message-ID: <3-HXFNsY0pIQDkRBl7sSnrBOjOrj33-QqSc_DDzxnjc=.00cfb135-9fcc-4587-97f3-88aa4af89aae@github.com>

On Thu, 3 Jun 2021 02:17:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If SYS_get_mempolicy is not defined then surely this must return false?

I don't think so.

No SYS_get_mempolicy symbol doesn't mean get_mempolicy syscall is unsupported.
It may still be invoked directly by its syscall number just like what the libnuma does [1].

The logic is:
  1) if defined(SYS_get_mempolicy) and SYS_get_mempolicy returns -1
       then get_mempolicy is surely no supported  
       so numa_syscall_check() must return fasle
  2) if not defined(SYS_get_mempolicy)
       then get_mempolicy may be supported or not
       so it can be wrong no matter what numa_syscall_check() returns.

However, for case 2), we can just let numa_syscall_check() return true.
This is fine because all the old JDKs (before jdk17) actually assume that get_mempolicy is always supported by default.

Another reason is that numa_syscall_check() is designed to do its best effort checks of numa related syscalls.
Even numa_syscall_check() return true, it still not guarantee that all numa required syscalls are supported since only get_mempolicy is checked currently.
But this is already enough for dockers with the default configuration.

Also, I think there should be SYS_get_mempolicy definition for almost all modern systems.
So the harmless false positive should be very very rare.

Thanks.

[1] https://github.com/numactl/numactl/blob/master/syscall.c#L121

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

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

From david.holmes at oracle.com  Thu Jun  3 02:57:47 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Jun 2021 12:57:47 +1000
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <3-HXFNsY0pIQDkRBl7sSnrBOjOrj33-QqSc_DDzxnjc=.00cfb135-9fcc-4587-97f3-88aa4af89aae@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
 <dmh2LOhL5ytpVSB2uUGYVurjI_Bo-PAdsjY8E_BN51w=.6fcedb04-3001-43a4-981c-c770957740f2@github.com>
 <3-HXFNsY0pIQDkRBl7sSnrBOjOrj33-QqSc_DDzxnjc=.00cfb135-9fcc-4587-97f3-88aa4af89aae@github.com>
Message-ID: <e34098b4-d700-7419-2001-707b0ebb8327@oracle.com>

On 3/06/2021 12:51 pm, Jie Fu wrote:
> On Thu, 3 Jun 2021 02:17:18 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> If SYS_get_mempolicy is not defined then surely this must return false?
> 
> I don't think so.
> 
> No SYS_get_mempolicy symbol doesn't mean get_mempolicy syscall is unsupported.
> It may still be invoked directly by its syscall number just like what the libnuma does [1].
> 
> The logic is:
>    1) if defined(SYS_get_mempolicy) and SYS_get_mempolicy returns -1
>         then get_mempolicy is surely no supported
>         so numa_syscall_check() must return fasle
>    2) if not defined(SYS_get_mempolicy)
>         then get_mempolicy may be supported or not
>         so it can be wrong no matter what numa_syscall_check() returns.
> 
> However, for case 2), we can just let numa_syscall_check() return true.
> This is fine because all the old JDKs (before jdk17) actually assume that get_mempolicy is always supported by default.
> 
> Another reason is that numa_syscall_check() is designed to do its best effort checks of numa related syscalls.
> Even numa_syscall_check() return true, it still not guarantee that all numa required syscalls are supported since only get_mempolicy is checked currently.
> But this is already enough for dockers with the default configuration.
> 
> Also, I think there should be SYS_get_mempolicy definition for almost all modern systems.
> So the harmless false positive should be very very rare.

Okay. So much trouble for so little code.

Thanks,
David
-----

> Thanks.
> 
> [1] https://github.com/numactl/numactl/blob/master/syscall.c#L121
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4277
> 

From dholmes at openjdk.java.net  Thu Jun  3 03:01:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Jun 2021 03:01:41 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
Message-ID: <J1Zm00l1hkVfGVKkgqjhe7X1ZDhycLTrxjy7qEm9uVI=.92a05816-313b-4505-bb6f-c40e2220cbd8@github.com>

On Wed, 2 Jun 2021 23:08:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   #ifdef SYS_get_mempolicy in numa_syscall_check

Marked as reviewed by dholmes (Reviewer).

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

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

From dholmes at openjdk.java.net  Thu Jun  3 03:01:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Jun 2021 03:01:42 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <3-HXFNsY0pIQDkRBl7sSnrBOjOrj33-QqSc_DDzxnjc=.00cfb135-9fcc-4587-97f3-88aa4af89aae@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
 <dmh2LOhL5ytpVSB2uUGYVurjI_Bo-PAdsjY8E_BN51w=.6fcedb04-3001-43a4-981c-c770957740f2@github.com>
 <3-HXFNsY0pIQDkRBl7sSnrBOjOrj33-QqSc_DDzxnjc=.00cfb135-9fcc-4587-97f3-88aa4af89aae@github.com>
Message-ID: <FCneYPTC8uwFUQaANccHpC6HFPKrsngsij-pvTc47Lc=.51d8b0e9-a9ec-4eba-85d4-32728f0cd3eb@github.com>

On Thu, 3 Jun 2021 02:48:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 2976:
>> 
>>> 2974:     return false;
>>> 2975:   }
>>> 2976: #endif
>> 
>> If SYS_get_mempolicy is not defined then surely this must return false?
>
>> If SYS_get_mempolicy is not defined then surely this must return false?
> 
> I don't think so.
> 
> No SYS_get_mempolicy symbol doesn't mean get_mempolicy syscall is unsupported.
> It may still be invoked directly by its syscall number just like what the libnuma does [1].
> 
> The logic is:
>   1) if defined(SYS_get_mempolicy) and SYS_get_mempolicy returns -1
>        then get_mempolicy is surely no supported  
>        so numa_syscall_check() must return fasle
>   2) if not defined(SYS_get_mempolicy)
>        then get_mempolicy may be supported or not
>        so it can be wrong no matter what numa_syscall_check() returns.
> 
> However, for case 2), we can just let numa_syscall_check() return true.
> This is fine because all the old JDKs (before jdk17) actually assume that get_mempolicy is always supported by default.
> 
> Another reason is that numa_syscall_check() is designed to do its best effort checks of numa related syscalls.
> Even numa_syscall_check() return true, it still not guarantee that all numa required syscalls are supported since only get_mempolicy is checked currently.
> But this is already enough for dockers with the default configuration.
> 
> Also, I think there should be SYS_get_mempolicy definition for almost all modern systems.
> So the harmless false positive should be very very rare.
> 
> Thanks.
> 
> [1] https://github.com/numactl/numactl/blob/master/syscall.c#L121

Okay.

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

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

From jiefu at openjdk.java.net  Thu Jun  3 03:06:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 3 Jun 2021 03:06:38 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <e34098b4-d700-7419-2001-707b0ebb8327@oracle.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <e34098b4-d700-7419-2001-707b0ebb8327@oracle.com>
Message-ID: <5nu_eU5dmMo6CvTAgmK6t3-hGAQ9NjamIzaJaNs8V8s=.fad8e6aa-be5e-46bf-b88c-a9e176720591@github.com>

On Thu, 3 Jun 2021 02:59:13 GMT, David Holmes <david.holmes at oracle.com> wrote:

> Okay. So much trouble for so little code.

Thanks @dholmes-ora .

Just enjoy the discussion with you all.
Thanks.

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

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

From lmesnik at openjdk.java.net  Thu Jun  3 04:15:39 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 04:15:39 GMT
Subject: Integrated: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <sRCdhpUR6OmolJltpgEYxE3zuRyr30gYxDLQPfMB0CU=.27f1f9e7-dc34-4dba-ab3e-7cf1f85de121@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

This pull request has now been integrated.

Changeset: 06f87cf4
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/06f87cf4419be9c1bffe996d5d476d30b0f86bf6
Stats:     7 lines in 1 file changed: 0 ins; 2 del; 5 mod

8266337: ThreadTimesClosure doesn't handle exceptions properly

Reviewed-by: dholmes, sspitsyn

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

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

From ysuenaga at openjdk.java.net  Thu Jun  3 04:48:37 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 3 Jun 2021 04:48:37 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <z3jJxWuQYLCx6glwzvc83Z65F_HmEyGrTJOBhv4R8lA=.cc34c0a6-5475-4e25-882a-c1696a8022d2@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <z3jJxWuQYLCx6glwzvc83Z65F_HmEyGrTJOBhv4R8lA=.cc34c0a6-5475-4e25-882a-c1696a8022d2@github.com>
Message-ID: <C1l-4ciXoT7egLFFXAinaHvT6O0M0HVovLvOv1sMpsU=.ee1589cb-715a-4f6a-9a74-5cde65aac1de@github.com>

On Thu, 3 Jun 2021 02:40:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm a bit confused. We seem to have this logic in two places - one in the VM and one in the JDK libraries. Shouldn't this fix look like the fix for JDK-8265836? Can we have just one chunk of code that handles all this?

I think it is better if we share the code between VM and JDK libraries (MBean). I think we can do it if we can add the functions to get metrics of native resources to JmmInterface, but it will be big refactoring.
This problem affects JFR and CPU time in thread dump AFAICS, so I want to fix it for next major release at first.

The logic in this PR is different from JDK-8265836, but it uses CPU time rather than elapsed time - it is same with JDK-8265836. So I cannot see the problem which is reported in JDK-8265836.

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

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

From ccheung at openjdk.java.net  Thu Jun  3 05:11:35 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 3 Jun 2021 05:11:35 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
 [v2]
In-Reply-To: <uQuxUGHlDoprOQXQNoHhfXjX1uUdJdaqasUUSUyNTMo=.8c054395-483d-41d0-90a7-e0f29fa68efe@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
 <uQuxUGHlDoprOQXQNoHhfXjX1uUdJdaqasUUSUyNTMo=.8c054395-483d-41d0-90a7-e0f29fa68efe@github.com>
Message-ID: <WFlg-2K0rsXLXp-tLpjETvoEAEflylvlz0tbqa1o4G8=.c73674c6-4892-43c0-92e6-ae478ea3124b@github.com>

On Thu, 3 Jun 2021 00:07:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.
>> 
>> The fix:
>> 
>> (1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`
>> 
>> (2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.
>> 
>> Testing -- Mach5 tiers 1-4 in progress
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good. In systemDictionaryShared.cpp

 `432   assert(DumpTimeTable_lock->owned_by_self(), "sanity");`

Can the above be changed to `assert_lock_strong(DumpTimeTable_lock);`?

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

Marked as reviewed by ccheung (Reviewer).

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

From david.holmes at oracle.com  Thu Jun  3 05:46:45 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Jun 2021 15:46:45 +1000
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <769b1c12-ab75-244b-1922-6c73618260d8@oracle.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <FHMp7SXlW_iN-CiE7-azdwlxqCm6px3Zc9OiZyJW-eU=.2c84e7ea-d492-42ef-91e1-3bed781ee0b7@github.com>
 <769b1c12-ab75-244b-1922-6c73618260d8@oracle.com>
Message-ID: <8dc0825c-65cc-bbe7-2bdd-3193ec166eef@oracle.com>

On 2/06/2021 1:02 pm, David Holmes wrote:
> On 2/06/2021 2:01 am, Daniel D.Daugherty wrote:
>> On Mon, 31 May 2021 17:09:48 GMT, Xin Liu <xliu at openjdk.org> wrote:
>>
>>>> The root cause of the intermittent failure is that _decorators in 
>>>> LogDecorations
>>>> may be inconsistent with LogOutput::_decorators. It could happen 
>>>> when gtest disables a
>>>> Log output via set_log_config(TestLogFileName, "all=off").
>>>>
>>>> Since we copy the entire logDecorations, it's reasonable to copy 
>>>> _decorator as well.
>>>> LogDecorator is a bitmask of uint. It's even smaller than a 
>>>> reference on LP64 platforms.
>>>>
>>>> This patch not only fixes intermittent crash in JDK-8267926, but 
>>>> also fixes JDK-8267952.
>>>> Two hazards of async logging in `LogConfiguration::configure_output` 
>>>> are eliminated.
>>>> This patch also adds a storestore barrier to make sure it's safe on 
>>>> weak consistency machines.
>>>
>>> Xin Liu has updated the pull request incrementally with one 
>>> additional commit since the last revision:
>>>
>>> ?? Increase reader's counter before creating LogDecoration.
>>
>> It looks like this failure is taking a bit of work to resolve. I've 
>> gone ahead and
>> ProblemListed the test. At this point we have 20 sightings in 
>> Tier[3-7]. Since
>> this failure is intermittent, I would want to see Tier[5-7] testing 
>> done before
>> the fix is integrated.
> 
> I've submitted the basic fix for tiers 5-7 testing.

That testing passed.

David
-----

> Xin: note you will need to merge with master and remove the test from 
> the Problem-list again as part of this PR.
> 
> Thanks,
> David
> -----
> 
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4257
>>

From xliu at openjdk.java.net  Thu Jun  3 05:48:55 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 05:48:55 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v6]
In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
Message-ID: <T-E48y6QjhD6xtg9jPIbKrLCdRSwUeFoZcsob7DtIrM=.49f27844-37cf-4f86-8d3c-287a0f100301@github.com>

> The root cause of the intermittent failure is that _decorators in LogDecorations 
> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
> Log output via set_log_config(TestLogFileName, "all=off").
> 
> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
> 
> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.

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

  Safeguard _stream is NULL due to rotation.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4257/files
  - new: https://git.openjdk.java.net/jdk/pull/4257/files/4184ba51..a52019d2

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

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

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

From darcy at openjdk.java.net  Thu Jun  3 05:48:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 3 Jun 2021 05:48:51 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <Y0cm8zWdeF6f_dArmQbnKbSwGnujsl7716bYgLRez6s=.5873deb5-ad78-4c75-97f3-c6b0c2ea083d@github.com>

On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8267630: Start of release updates for JDK 18

JDK 18 is right around the corner, time for the usual start-of-release changeset for review.

Typical structure for these kinds of changes. I'll update the symbol file information of JDK 17 b25 after that build is promoted.

Usual updates to SourceVersion, javac, HotSpot, and version-oriented tests.

Please also review the related CSRs:

    JDK-8268156: Add SourceVersion.RELEASE_18
    https://bugs.openjdk.java.net/browse/JDK-8268156

    JDK-8268157: Add source 18 and target 18 to javac
    https://bugs.openjdk.java.net/browse/JDK-8268157

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

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

From darcy at openjdk.java.net  Thu Jun  3 05:48:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 3 Jun 2021 05:48:51 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18
Message-ID: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>

8267630: Start of release updates for JDK 18

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

Commit messages:
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Clean langtools test run.
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ef01e478...9c7c88bf

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

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

From iris at openjdk.java.net  Thu Jun  3 05:58:37 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 3 Jun 2021 05:58:37 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <y_Rmu3hd27hUEaVR1DBbFWho8ufmRuebY6j5zLP73I4=.d8b72ac2-58c1-46a7-9fb0-cf6a2e97d6cc@github.com>

On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8267630: Start of release updates for JDK 18

Marked as reviewed by iris (Reviewer).

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

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

From xliu at openjdk.java.net  Thu Jun  3 06:08:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 06:08:40 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <v07YgQ41bMAlGyEqZNNhQSvmdGhn7FvT2DckqtfDWPA=.1bed8dd4-68fe-4f21-ac09-2bb5415b6808@github.com>
Message-ID: <eO0FxxavZKJYjaHNxnhW7xUf7TGrjY0rzvc_fPZAw7I=.f722564a-6fe4-4c37-bbac-5d8400327314@github.com>

On Tue, 1 Jun 2021 05:09:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase reader's counter before creating LogDecoration.
>
> I put the latest patch through our tier 1-4 testing and it crashed in tier 3 on Linux-Aarch64:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x0000ffff40820720, pid=3972473, tid=3972481
> #
> # JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-05-31-2211099.david.holmes.jdk-dev4.git, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # C  [libc.so.6+0x60720]  flockfile+0x0
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/a4f8fba9-f017-4328-b286-c66b6a97143d-S808/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/42993029-a18a-48c4-9a4d-108aee7b3811/runs/a38508fe-5d43-48ad-b70a-61f3e712fcd8/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.3972473)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> ---------------  S U M M A R Y ------------
> 
> Command Line: -XX:+ExecutingUnitTests -Xlog:async 
> 
> Host: AArch64, 6 cores, 46G, Oracle Linux Server release 8.3
> Time: Mon May 31 22:37:04 2021 UTC elapsed time: 3.758723 seconds (0d 0h 0m 3s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x0000aaadf32b1e10):  Thread "AsyncLog Thread" [stack: 0x0000fffefdaa0000,0x0000fffefdca0000] [id=3972481]
> 
> Stack: [0x0000fffefdaa0000,0x0000fffefdca0000],  sp=0x0000fffefdc9e510,  free space=2041k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libc.so.6+0x60720]  flockfile+0x0
> V  [libjvm.so+0x1508058]  LogFileOutput::write_blocking(LogDecorations const&, char const*)+0x38
> V  [libjvm.so+0x1502764]  AsyncLogWriter::run()+0x2c0
> V  [libjvm.so+0x1a49d08]  Thread::call_run()+0xf8
> V  [libjvm.so+0x1766f18]  thread_native_entry(Thread*)+0x108
> C  [libpthread.so.0+0x76e0]  start_thread+0x198

hi, @dholmes-ora , 

I have another guess. This crash sight could also be caused by log rotation!

Stack: [0x0000fffefdaa0000,0x0000fffefdca0000], sp=0x0000fffefdc9e510, free space=2041k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.6+0x60720] flockfile+0x0
V [libjvm.so+0x1508058] LogFileOutput::write_blocking(LogDecorations const&, char const*)+0x38
V [libjvm.so+0x1502764] AsyncLogWriter::run()+0x2c0
V [libjvm.so+0x1a49d08] Thread::call_run()+0xf8
V [libjvm.so+0x1766f18] thread_native_entry(Thread*)+0x108
C [libpthread.so.0+0x76e0] start_thread+0x198


It's possible that `write_blocking` is waken up from _rotation_semaphore.wait(), and proceed with writing. 


int LogFileOutput::write_blocking(const LogDecorations& decorations, const char* msg) {
  _rotation_semaphore.wait();

  int written = LogFileStreamOutput::write(decorations, msg);
....
}


`rotate()` could fail at os::fopen() due to space or fnode limitation. It will leave _stream == NULL and make 
` LogFileStreamOutput::write(decorations, msg)` fail at flockfile(NULL). 


void LogFileOutput::rotate() {
...
  _stream = os::fopen(_file_name, FileOpenMode);
  if (_stream == NULL) {
    errstream->print_cr("Error opening log file '%s': %s",
                        _file_name, os::strerror(errno));
    return false;
  }


I don't know how to make it happen. The easiest way to verify my guess is to grep  'Error opening log file' if you still have those files. or you may try this revision. I remove AsyncLogGtest.java from problemlist. 

https://github.com/openjdk/jdk/pull/4257/commits/a52019d2e413398b97ed36463cd0d439f3caed4d

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

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

From xliu at openjdk.java.net  Thu Jun  3 06:16:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 06:16:37 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v6]
In-Reply-To: <T-E48y6QjhD6xtg9jPIbKrLCdRSwUeFoZcsob7DtIrM=.49f27844-37cf-4f86-8d3c-287a0f100301@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <T-E48y6QjhD6xtg9jPIbKrLCdRSwUeFoZcsob7DtIrM=.49f27844-37cf-4f86-8d3c-287a0f100301@github.com>
Message-ID: <wurDBVv02XgCz8xUdOy89nLMYWr5VuoYU-zaMxdN6fI=.f6ec206d-4578-43b8-af6b-49a9dffd1aa2@github.com>

On Thu, 3 Jun 2021 05:48:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>> 
>> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
>> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
>> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Safeguard _stream is NULL due to rotation.

src/hotspot/share/logging/logConfiguration.cpp line 282:

> 280:   if (!enabled) {
> 281:     for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
> 282:       assert(!ts->has_output(output), "The node of output should been removed in ts->set_output_level.");

should be removed by ts->set_output_level()

test/hotspot/gtest/logging/test_logConfiguration.cpp line 305:

> 303:     }
> 304: 
> 305:     // Take turn logging with different decorators, either None or All.

This comment is wrong.  I turn on/off the tagset logging here.

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

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

From xliu at openjdk.java.net  Thu Jun  3 07:35:11 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 07:35:11 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v7]
In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
Message-ID: <o2X4TRa5PvTjTomTFD9Un8iMo4t0MlCUSDwlFB3I_yM=.754f91c6-ad3c-4cdd-81c9-15d600bf5972@github.com>

> The root cause of the intermittent failure is that _decorators in LogDecorations 
> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
> Log output via set_log_config(TestLogFileName, "all=off").
> 
> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
> 
> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.

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

  Use RAII to protect _rotation_semaphore.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4257/files
  - new: https://git.openjdk.java.net/jdk/pull/4257/files/a52019d2..07a79051

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=05-06

  Stats: 31 lines in 3 files changed: 14 ins; 13 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257

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

From rehn at openjdk.java.net  Thu Jun  3 07:49:38 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 3 Jun 2021 07:49:38 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
Message-ID: <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>

On Wed, 2 Jun 2021 18:10:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> We have three options here:
>> 1: "If the handshake operation is not completed it must be on at least one queue."
>> 2: "If the handshake operation is completed it is not on any queue."
>> 3: "It may be on queue while completed and may not be queue when not completed, it depends."
>> 
>> With the polling mechanism saying you must stop while the queue is not empty, the operation is removed after it is executed, option 1 seemed preferable to me.
>> Specially if we want a simpler easier model to avoid any further such bugs as this.
>> 
>> This means removal from queue happens after decrement of _pending_threads.
>> remove_op() -> pop() gives no ordering guarantee, those comes from the mutex.
>> 
>> The technical note on the current implementation of the queue is:
>> Only first can be read without lock and the implementation of first manipulation is done with a CAS.
>> So a side-effect of current implementation is that the only thing that can be seen will be ordered.
>> 
>> Since we running in slowpath there is no need to reduce ordering to a minimum and we can thus change the queue implementation since it have no guarantees to do any ordering without worrying about someone (ab)using side-effects.
>> 
>> Do you agree?
>
> Right, but I don't see why the change of just using the queue to check for pending handshakes matters here. This release was to ensure that if the handshakee executed the closure, the memory operations executed in the handshake would be visible to the vmthread/handshaker after seeing the operation was completed (matched with the acquired after is_completed()). What could be the issue if this is not a full fence?

"Change of just using the queue to check for pending handshakes": also means we must remove the handshake from the queue after it have been executed.
I consider the decrement as the marking of "it have been executed".

Therefore anything after the decrement, should stay after and not float above the dec, to follow the protocol.
If disregard ordering side-effects when removing the last in queue with CAS, if the removal happens before the decrement means if the handshakee ask "should process" it could say no before we decrement.

This release to the removal of the operation is match with the acquire on is_empty().
Normally the removal would had used the release from the mutex lock, but here we hold the lock over several operations.

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

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

From xliu at openjdk.java.net  Thu Jun  3 07:58:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 07:58:37 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v7]
In-Reply-To: <o2X4TRa5PvTjTomTFD9Un8iMo4t0MlCUSDwlFB3I_yM=.754f91c6-ad3c-4cdd-81c9-15d600bf5972@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <o2X4TRa5PvTjTomTFD9Un8iMo4t0MlCUSDwlFB3I_yM=.754f91c6-ad3c-4cdd-81c9-15d600bf5972@github.com>
Message-ID: <O-gkUqeuzXiuhFo4xvXQ9bt0fTYr_YBbFPXBIBjWn2U=.5ff46418-758f-4185-87d5-00c7fae8b963@github.com>

On Thu, 3 Jun 2021 07:35:11 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>> 
>> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.
>> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. 
>> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use RAII to protect _rotation_semaphore.

I double down that one flush() can eliminate two hazards. 2 concurrent tests are provided to demonstrate `LogConfiguration::configure_output` is MT-safe. 

Previously,  the test was in bad shape which cause unnecessary rotation and quite big(100M+) on /tmp. I guess that's the root cause of failure on Linux/aarch64. patched.

This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952.

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

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

From xliu at openjdk.java.net  Thu Jun  3 08:01:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 08:01:37 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v3]
In-Reply-To: <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <BM1zxmJYaPXjCrQf1HNdjEdSA5LY9zrshsmzS_cGhx0=.ee4d83eb-f930-41b2-840d-743f5573e93b@github.com>
 <iRX4O8Ahqx12QisLfdLDz_6V3vqoRWLG5camUAyJZeE=.0961b387-388b-4ceb-a750-aa870a80ee2c@github.com>
Message-ID: <Pcj4HMBNIhrj2KkIvKNJiiAhzGLjVQHSPmgljDsNLSA=.3cb8c7d7-c3bd-4939-af28-ddf57987aa11@github.com>

On Mon, 31 May 2021 22:24:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase reader's counter before creating LogDecoration.
>
> src/hotspot/share/logging/logConfiguration.cpp line 267:
> 
>> 265:   //
>> 266:   // LogDecorator is a set of decorators represented in a uint. sizeof(uinit) is not greater than a machine word,
>> 267:   // so store of it is atomic on the mainstream processors. I.e. readers see either its older value or new value.
> 
> We should use Atomic::store and Atomic::load regardless.

I just comment out why it's MT-safe here. if it's necessary, we can use a new JBS issue to change it to Atomic::store.

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

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

From xliu at openjdk.java.net  Thu Jun  3 09:06:02 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 09:06:02 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v8]
In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
Message-ID: <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>

> The root cause of the intermittent failure is that _decorators in LogDecorations 
> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
> Log output via set_log_config(TestLogFileName, "all=off").
> 
> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.

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

  Revert back to the basic bugfix and remove AsyncLogGtest.java from ProblemList.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4257/files
  - new: https://git.openjdk.java.net/jdk/pull/4257/files/07a79051..199f2535

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=06-07

  Stats: 171 lines in 9 files changed: 9 ins; 154 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257

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

From xliu at openjdk.java.net  Thu Jun  3 09:10:44 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 09:10:44 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v8]
In-Reply-To: <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
Message-ID: <DtykrnT6ngyEhAw5Eiu50tvp_x_JGONL1RrZtqWQ424=.ccadc4fd-2b47-422e-b5f2-20f8cc997314@github.com>

On Thu, 3 Jun 2021 09:06:02 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back to the basic bugfix and remove AsyncLogGtest.java from ProblemList.

Sorry.  I just realize a big problem of mine. I try to fix multiple problems in one same PR. 
That makes this PR messy and also confuse reviewers.  Let me revert them back first and just focus on JDK-8267926. 

This is actually the first revision.

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

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

From xliu at openjdk.java.net  Thu Jun  3 09:48:51 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 09:48:51 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails
Message-ID: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>

8268165: AsyncLogging will crash if rotate() fails

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

Commit messages:
 - 8268165: AsyncLogging will crash if rotate() fails

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

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

From erikj at openjdk.java.net  Thu Jun  3 12:51:36 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 3 Jun 2021 12:51:36 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <94PX9MLJgRcWFUR1VQtRdowvllf6j9JcTPPPLHXh-JM=.822be67f-5513-42a8-9342-78da0b315807@github.com>

On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8267630: Start of release updates for JDK 18

Build change looks good.

Please be aware of the incoming change https://bugs.openjdk.java.net/browse/JDK-8263468 which will add another version field to version-numbers.conf, which may need to be updated too. The exact policy around that is still unclear though.

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

Marked as reviewed by erikj (Reviewer).

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

From jiefu at openjdk.java.net  Thu Jun  3 12:58:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 3 Jun 2021 12:58:40 GMT
Subject: Integrated: 8268014: Build failure on SUSE Linux Enterprise Server
 11.4 (s390x) due to 'SYS_get_mempolicy' was not declared
In-Reply-To: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
Message-ID: <hswUNkuNNwFqgh1lB1LK2NOpJ94aQTWK9vTvugLAkmo=.501cd433-9bb8-4a45-83ee-3fc6666cd14d@github.com>

On Tue, 1 Jun 2021 08:11:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
> 
> @dholmes-ora had reminded me of this bug in [1].
> But I missed the fact that ZGC is currently only built on x64 and aarch64.
> And I'm sorry for this breakage.
> 
> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
> [2] https://github.com/numactl/numactl/blob/master/syscall.c

This pull request has now been integrated.

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

8268014: Build failure on SUSE Linux Enterprise Server 11.4 (s390x) due to 'SYS_get_mempolicy' was not declared

Reviewed-by: dholmes, mdoerr, mbaesken

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

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

From rschmelter at openjdk.java.net  Thu Jun  3 13:32:36 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Thu, 3 Jun 2021 13:32:36 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <gZNkbOjtpmgnX_a6Nd5eVmZUZy1duo09l5SP07xO0xc=.b026afaf-969c-4421-a9bc-898716042730@github.com>

On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows flags (although complied fine)

Yeah, I tjhink the O_NOCTTY is more a theoretical consideration. I've never seen problems in practice.

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

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

From coleenp at openjdk.java.net  Thu Jun  3 14:18:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 3 Jun 2021 14:18:37 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes
In-Reply-To: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
Message-ID: <z0uhn55TMsdK5CeNh4YazWGYdkr-dYxsHxI2-hI4WBo=.90fa44c1-2a65-43a6-b494-c3b84512f91c@github.com>

On Thu, 3 Jun 2021 00:36:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 
> 
> Requested by @rose00 (sorry I took a long time ....).

Looks good with some minor suggestions.

src/hotspot/share/memory/allocation.hpp line 277:

> 275:   //
> 276:   // The following functions are required by MetadataFactory::free_metadata():
> 277:   //   bool on_stack() { return false; } // DEBUG only

I don't think the // DEBUG only comment is correct.  on_stack is used in product mode.  Can you remove this?

src/hotspot/share/memory/allocation.hpp line 283:

> 281:   // Elsewhere in the hierarchy of MetaspaceObj, type() and/or size() can be static
> 282:   // if constant.
> 283: 

maybe move this up to be under 275 because it talks about those.

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

Marked as reviewed by coleenp (Reviewer).

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

From pchilanomate at openjdk.java.net  Thu Jun  3 15:32:47 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 3 Jun 2021 15:32:47 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
Message-ID: <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>

On Thu, 3 Jun 2021 07:46:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Right, but I don't see why the change of just using the queue to check for pending handshakes matters here. This release was to ensure that if the handshakee executed the closure, the memory operations executed in the handshake would be visible to the vmthread/handshaker after seeing the operation was completed (matched with the acquired after is_completed()). What could be the issue if this is not a full fence?
>
> "Change of just using the queue to check for pending handshakes": also means we must remove the handshake from the queue after it have been executed.
> I consider the decrement as the marking of "it have been executed".
> 
> Therefore anything after the decrement, should stay after and not float above the dec, to follow the protocol.
> If disregard ordering side-effects when removing the last in queue with CAS, if the removal happens before the decrement means if the handshakee ask "should process" it could say no before we decrement.
> 
> This release to the removal of the operation is match with the acquire on is_empty().
> Normally the removal would had used the release from the mutex lock, but here we hold the lock over several operations.

Ok, although since all it matters for is_empty() is that there is at least one element in the queue and to remove the last element we always use a CAS it should be okay. I now realize that we could have also removed the operation from the queue as before if it is not the last one, so that would save the second traversal of the queue. But I see that if we want to maintain the invariant "If the handshake operation is not completed it must be on at least one queue" then we need to do it like this.

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

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

From pchilanomate at openjdk.java.net  Thu Jun  3 15:32:47 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 3 Jun 2021 15:32:47 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
Message-ID: <kkxsShY5VQ1CjSJ_YTkQOgyeYF4xmRRRISCRMYkb6Xk=.1e7e334a-9eac-463a-8754-11bd08997772@github.com>

On Fri, 28 May 2021 07:45:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - Fix

Marked as reviewed by pchilanomate (Committer).

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

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

From dcubed at openjdk.java.net  Thu Jun  3 15:51:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 15:51:44 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
Message-ID: <2TsYLSoWLAhqo4ofiKBCfpss9fr0b2h0SuSkJRDBAIo=.d7c5a2d7-70eb-4b6d-9cbf-4f99153cfa54@github.com>

On Fri, 28 May 2021 07:45:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - Fix

Has there been an update since my last review? I recorded that I
reviewed v02 and that appears to still be the current version.

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

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

From dcubed at openjdk.java.net  Thu Jun  3 16:11:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 16:11:46 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
Message-ID: <xjcNh2QHobv9e7sJ6BA-fLG2QER63VWmqpfPMPBps1k=.aa0cdcab-b9ca-41b4-89da-cf6878c37f7e@github.com>

On Fri, 28 May 2021 07:45:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - Fix

I've re-reviewed v02 and this time I used the full webrev. It was much
easier to wrap my head around this time. It could also be because I'm
re-reviewing much earlier in the day. :-)

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

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

From dcubed at openjdk.java.net  Thu Jun  3 16:11:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 16:11:46 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
Message-ID: <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>

On Thu, 3 Jun 2021 15:27:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> "Change of just using the queue to check for pending handshakes": also means we must remove the handshake from the queue after it have been executed.
>> I consider the decrement as the marking of "it have been executed".
>> 
>> Therefore anything after the decrement, should stay after and not float above the dec, to follow the protocol.
>> If disregard ordering side-effects when removing the last in queue with CAS, if the removal happens before the decrement means if the handshakee ask "should process" it could say no before we decrement.
>> 
>> This release to the removal of the operation is match with the acquire on is_empty().
>> Normally the removal would had used the release from the mutex lock, but here we hold the lock over several operations.
>
> Ok, although since all it matters for is_empty() is that there is at least one element in the queue and to remove the last element we always use a CAS it should be okay. I now realize that we could have also removed the operation from the queue as before if it is not the last one, so that would save the second traversal of the queue. But I see that if we want to maintain the invariant "If the handshake operation is not completed it must be on at least one queue" then we need to do it like this.

Did you guys decide the comment needed updating or not?
I can't figure that out from the above.

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

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

From dcubed at openjdk.java.net  Thu Jun  3 16:11:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 16:11:48 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <jBqg1OTbfHSS1huaLf3XoR0o6gmlFORw32v4QZsfaiw=.0162e40a-a248-4adb-93ae-dfe51a1e9808@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <T1CdgUfAqWXEL0NqDMvP7bnkL3ojeRBeL9gPJ9FzFRI=.5231a70e-b8ba-4430-a61c-17d4cb841e66@github.com>
 <jBqg1OTbfHSS1huaLf3XoR0o6gmlFORw32v4QZsfaiw=.0162e40a-a248-4adb-93ae-dfe51a1e9808@github.com>
Message-ID: <Kh2UmdsSvTc5nRJRMNpCQelCRayU7ct9ab3dyr7Obb4=.7ca840cb-e2f7-4dbc-b435-9161f7c7eab0@github.com>

On Wed, 2 Jun 2021 09:20:11 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/handshake.cpp line 429:
>> 
>>> 427:   assert(_handshakee == Thread::current(), "Must be called by self");
>>> 428:   assert(_lock.owned_by_self(), "Lock must be held");
>>> 429:   return _queue.peek();
>> 
>> `get_op_for_self()` name does not match the `peek()` operation.
>> The new name should be `peek_op_for_self()`.
>
> The method retrieves the next operation to be executed, hence 'get'.
> That the method uses a queue which provides a pop() and peek() is an implementation, there is no value for the user of  get_op_for_self() to know how this is done?

Agreed there is no value in that distinction. I was having trouble getting my head
wrapped around what the code was trying to do.

>> src/hotspot/share/runtime/handshake.cpp line 445:
>> 
>>> 443:   assert(_handshakee != Thread::current(), "Must not be called by self");
>>> 444:   assert(_lock.owned_by_self(), "Lock must be held");
>>> 445:   return _queue.peek(non_self_queue_filter);
>> 
>> `get_op()` name does not match the peek() operation.
>> The new name should be `peek_op()`.
>
> The method retrieves the next operation to be executed, hence 'get'.
> That the method uses a queue which provides a pop() and peek() is an implementation, there is no value for the user of  get_op_for_self() to know how this is done?

Agreed.

>> src/hotspot/share/runtime/handshake.cpp line 452:
>> 
>>> 450:   MatchOp mo(op);
>>> 451:   HandshakeOperation* ret = _queue.pop(mo);
>>> 452:   assert(ret == op, "OP missing from queue");
>> 
>> Perhaps this for the assert() mesg:
>> `  assert(ret == op, "popped op must match requested op.");
>> 
>> Also, I would name this one `pop_op()` instead of `remove_op()`.
>
> Changed assert.
> 
> In the handshake code we need two operation get operation and remove operation.
> They happen to be implemented with peek and pop.
> So from the user perspective he wants to remove an operation and thus uses the remove method.
> Since we do not want any return from this method, renaming it pop and not return anything is just confusing, isn't it?

Agreed.

>> src/hotspot/share/runtime/handshake.cpp line 483:
>> 
>>> 481:         HandleMark hm(_handshakee);
>>> 482:         PreserveExceptionMark pem(_handshakee);
>>> 483:         op->do_handshake(_handshakee); // acquire, op removed after
>> 
>> Why `acquire`? Perhaps:
>> `// peek and handshake with op; op removed after`
>
> It's mean do_handshake provide acquire thus op is removed after.

Ok.

>> src/hotspot/share/runtime/handshake.cpp line 489:
>> 
>>> 487:         // The destructor ~PreserveExceptionMark touches the exception oop so it must not be executed,
>>> 488:         // since a safepoint may be in-progress when returning from the async handshake.
>>> 489:         op->do_handshake(_handshakee); // acquire, op removed after
>> 
>> Why acquire? Perhaps:
>> // peek and handshake with op; op removed after
>
> It's mean do_handshake provide acquire thus op is removed after.

Ok.

>> src/hotspot/share/runtime/handshake.cpp line 583:
>> 
>>> 581: 
>>> 582:   set_active_handshaker(current_thread);
>>> 583:   op->do_handshake(_handshakee); // acquire, op removed after
>> 
>> Why acquire? Perhaps:
>> // peek and handshake with op; op removed after
>
> It's mean do_handshake provide acquire thus op is removed after.

Ok.

>> src/hotspot/share/utilities/filterQueue.inline.hpp line 127:
>> 
>>> 125:   do {
>>> 126:     if (match_func(cur->_data)) {
>>> 127:       match = cur;
>> 
>> Hmmm.... I was expecting a break after this match.
>> Is there a reason to continue the loop?
>> 
>> But now I'm realizing that I'm confused since this is called `peek()`, but
>> it's not really peeking at the head of the queue. It is searching the entire
>> queue for a match.
>
> It is a FIFO queue, which provides inserts at the end (push) and retrieves at the front of the queue (pop/peek).
> Push inserts at tail and pop/peek looks at head. (maybe these should be named differently to reflect this better, but that is another PR :) )
> 
> To provide lock-free inserts the queue only have a tail pointer.
> This enabled us to do concurrent inserts with other inserts and/or another serialized operation, such as peek.
> To get to the front of the queue we must always walk until the end.
> 
> This means peek is peeking at the head (with a filter).
> Conceptually we generate a queue from that filter and from that virtual queue we peek at it's head.
> 
> Tail->A1->A2->A3->A4->A5
> Filter = even
> Virtual tail->A2->A4
> Virtual head = A4
> 
> To get to A4 we walk and apply the filter, the last match will be the head we are looking to peek at.

So it's not just find _a_ match. It is find the _last_ match. OK.

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

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

From iklam at openjdk.java.net  Thu Jun  3 16:24:36 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 3 Jun 2021 16:24:36 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes
In-Reply-To: <z0uhn55TMsdK5CeNh4YazWGYdkr-dYxsHxI2-hI4WBo=.90fa44c1-2a65-43a6-b494-c3b84512f91c@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
 <z0uhn55TMsdK5CeNh4YazWGYdkr-dYxsHxI2-hI4WBo=.90fa44c1-2a65-43a6-b494-c3b84512f91c@github.com>
Message-ID: <nNJU9yWc82onz8fRGzRoIhIUe96UcZv_ki09tfRfbdQ=.73bb1607-e070-4abb-9c4b-34ea8bbed99d@github.com>

On Thu, 3 Jun 2021 14:14:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 
>> 
>> Requested by @rose00 (sorry I took a long time ....).
>
> src/hotspot/share/memory/allocation.hpp line 277:
> 
>> 275:   //
>> 276:   // The following functions are required by MetadataFactory::free_metadata():
>> 277:   //   bool on_stack() { return false; } // DEBUG only
> 
> I don't think the // DEBUG only comment is correct.  on_stack is used in product mode.  Can you remove this?

Hmm .... in product code, there's no use of `MetaspaceObj::on_stack()`, but there's use of `Metadata::on_stack()`.

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

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

From ccheung at openjdk.java.net  Thu Jun  3 16:42:50 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 3 Jun 2021 16:42:50 GMT
Subject: RFR: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
Message-ID: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>

Please review this patch for disabling the `VerifyDependencies` option when running the CDS MethodHandle tests with debug build. It reduces the time required for running the tests a lot.
e.g. total time for running the `appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` test with debug build:
before 489.102s
after 62.721s

The patch passed tier1 and tier2 tests.

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

Commit messages:
 - 8268095: CDS MethodHandle tests should add -XX:-VerifyDependencies

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

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

From pchilanomate at openjdk.java.net  Thu Jun  3 16:44:46 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 3 Jun 2021 16:44:46 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
Message-ID: <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>

On Thu, 3 Jun 2021 16:06:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Ok, although since all it matters for is_empty() is that there is at least one element in the queue and to remove the last element we always use a CAS it should be okay. I now realize that we could have also removed the operation from the queue as before if it is not the last one, so that would save the second traversal of the queue. But I see that if we want to maintain the invariant "If the handshake operation is not completed it must be on at least one queue" then we need to do it like this.
>
> Did you guys decide the comment needed updating or not?
> I can't figure that out from the above.

Maybe it should be added in the comment that the fence is also used to prevent removing of the operation to float above marking the operation as completed so we keep the invariant: "If the handshake operation is not completed it must be on at least one queue".

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

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

From iklam at openjdk.java.net  Thu Jun  3 16:52:38 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 3 Jun 2021 16:52:38 GMT
Subject: RFR: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
In-Reply-To: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
References: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
Message-ID: <D_udTa5Qo5VtyvYAxZhgwoP1AhEVS3BN3S8JEOs34DI=.6e851e19-2a66-4b16-9d7f-be9e993fd381@github.com>

On Thu, 3 Jun 2021 16:34:34 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for disabling the `VerifyDependencies` option when running the CDS MethodHandle tests with debug build. It reduces the time required for running the tests a lot.
> e.g. total time for running the `appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` test with debug build:
> before 489.102s
> after 62.721s
> 
> The patch passed tier1 and tier2 tests.

Looks good. As I can see, the changes are in the .sh files, and the .java files are mechanically regenerated from the .sh files.

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

Marked as reviewed by iklam (Reviewer).

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

From pchilanomate at openjdk.java.net  Thu Jun  3 16:58:38 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 3 Jun 2021 16:58:38 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
 <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
Message-ID: <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJYTThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>

On Thu, 3 Jun 2021 16:41:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Did you guys decide the comment needed updating or not?
>> I can't figure that out from the above.
>
> Maybe it should be added in the comment that the fence is also used to prevent removing of the operation to float above marking the operation as completed so we keep the invariant: "If the handshake operation is not completed it must be on at least one queue".

I still think we can keep the previous memory_order_release order, but if this stricter order makes it easier to read for others then I'm okay.

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

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

From iignatyev at openjdk.java.net  Thu Jun  3 17:29:36 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 3 Jun 2021 17:29:36 GMT
Subject: RFR: 8267917: mark hotspot containers tests which ignore external
 VM flags
In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
Message-ID: <v-taDHR1lWiKnpGxoGh7k5OppOhKi143CB2XNKRiUFg=.8d64c751-ff5b-4bb9-b0b9-f50f292d3914@github.com>

On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags?
> 
> attn: @mseledts
> 
> Cheers,
> -- Igor

Thanks, Misha!

can I get a second Review?

-- Igor

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

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

From ccheung at openjdk.java.net  Thu Jun  3 18:03:33 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 3 Jun 2021 18:03:33 GMT
Subject: RFR: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
In-Reply-To: <D_udTa5Qo5VtyvYAxZhgwoP1AhEVS3BN3S8JEOs34DI=.6e851e19-2a66-4b16-9d7f-be9e993fd381@github.com>
References: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
 <D_udTa5Qo5VtyvYAxZhgwoP1AhEVS3BN3S8JEOs34DI=.6e851e19-2a66-4b16-9d7f-be9e993fd381@github.com>
Message-ID: <CW4hibPiYj3eYPjzjlvbleYPYlmkRt-6WCT3wQSNQQ0=.f0b07fb4-adc7-4734-84ac-aa0a24f8193e@github.com>

On Thu, 3 Jun 2021 16:49:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this patch for disabling the `VerifyDependencies` option when running the CDS MethodHandle tests with debug build. It reduces the time required for running the tests a lot.
>> e.g. total time for running the `appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` test with debug build:
>> before 489.102s
>> after 62.721s
>> 
>> The patch passed tier1 and tier2 tests.
>
> Looks good. As I can see, the changes are in the .sh files, and the .java files are mechanically regenerated from the .sh files.

@iklam Thanks for the review.

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

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

From hseigel at openjdk.java.net  Thu Jun  3 19:00:59 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 3 Jun 2021 19:00:59 GMT
Subject: RFR: 8267917: mark hotspot containers tests which ignore external
 VM flags
In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
Message-ID: <Tje4ULG1yt1ZGCF62lTR7A1lUlOxleS6Ge2nxjJc-xs=.d72fbf0c-63b0-4b3d-b67b-efade9e08320@github.com>

On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags?
> 
> attn: @mseledts
> 
> Cheers,
> -- Igor

Would this change prevent these tests from being running in many cases, such as  if -Xint or -Xcomp was specified for the test run?

Were tests failing because of the external flags?

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

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

From phh at openjdk.java.net  Thu Jun  3 19:05:55 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 3 Jun 2021 19:05:55 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v8]
In-Reply-To: <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
Message-ID: <-FEGREjxDfk805m3-cnP2a-vzFNDKFhbWv6UOjntiKA=.a76d3764-67dd-4f0c-a7a4-e265ff670963@github.com>

On Thu, 3 Jun 2021 09:06:02 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back to the basic bugfix and remove AsyncLogGtest.java from ProblemList.

This makes sense. If _decorators is set to a reference to an ephemeral value, random memory stomps may ensue.

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

Marked as reviewed by phh (Reviewer).

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

From hseigel at openjdk.java.net  Thu Jun  3 19:25:02 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 3 Jun 2021 19:25:02 GMT
Subject: RFR: 8267917: mark hotspot containers tests which ignore external
 VM flags
In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
Message-ID: <csHG1NeJo1mkdfzKvnZe64N6Crm6Q1oWnXviklt3OJc=.831f9e83-71a2-4f53-be90-1098b37a5197@github.com>

On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags?
> 
> attn: @mseledts
> 
> Cheers,
> -- Igor

LGTM  Thanks for doing this.
Harold

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

Marked as reviewed by hseigel (Reviewer).

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

From dcubed at openjdk.java.net  Thu Jun  3 19:36:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 19:36:17 GMT
Subject: Integrated: 8268189: ProblemList
 compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode
Message-ID: <WELlnd4L20i5XD1tOMpHBxmHpxQuBrB_pWPrENdcAHo=.8239a95e-57c5-43ca-862f-4b86590d7719@github.com>

A trivial fix to ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode.

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

Commit messages:
 - 8268189: ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode

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

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

From mikael at openjdk.java.net  Thu Jun  3 19:36:17 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 3 Jun 2021 19:36:17 GMT
Subject: Integrated: 8268189: ProblemList
 compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode
In-Reply-To: <WELlnd4L20i5XD1tOMpHBxmHpxQuBrB_pWPrENdcAHo=.8239a95e-57c5-43ca-862f-4b86590d7719@github.com>
References: <WELlnd4L20i5XD1tOMpHBxmHpxQuBrB_pWPrENdcAHo=.8239a95e-57c5-43ca-862f-4b86590d7719@github.com>
Message-ID: <kxluuopIuWi3HxUtCGpeYvi-f5Pg3cey_5hQOtd8KeE=.56099670-c5a6-49b5-8fd9-78a87ae58718@github.com>

On Thu, 3 Jun 2021 19:24:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode.

Marked as reviewed by mikael (Reviewer).

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

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

From dcubed at openjdk.java.net  Thu Jun  3 19:36:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 19:36:17 GMT
Subject: Integrated: 8268189: ProblemList
 compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode
In-Reply-To: <kxluuopIuWi3HxUtCGpeYvi-f5Pg3cey_5hQOtd8KeE=.56099670-c5a6-49b5-8fd9-78a87ae58718@github.com>
References: <WELlnd4L20i5XD1tOMpHBxmHpxQuBrB_pWPrENdcAHo=.8239a95e-57c5-43ca-862f-4b86590d7719@github.com>
 <kxluuopIuWi3HxUtCGpeYvi-f5Pg3cey_5hQOtd8KeE=.56099670-c5a6-49b5-8fd9-78a87ae58718@github.com>
Message-ID: <SjWQ0CH4Xc_gcWA0XtJlfAyN5j_gwDm_G_yQIyujgFw=.92c6f2ba-5ade-40ca-b1d4-ea90d6b1e2b1@github.com>

On Thu, 3 Jun 2021 19:29:15 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

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

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

From dcubed at openjdk.java.net  Thu Jun  3 19:36:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 19:36:18 GMT
Subject: Integrated: 8268189: ProblemList
 compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode
In-Reply-To: <WELlnd4L20i5XD1tOMpHBxmHpxQuBrB_pWPrENdcAHo=.8239a95e-57c5-43ca-862f-4b86590d7719@github.com>
References: <WELlnd4L20i5XD1tOMpHBxmHpxQuBrB_pWPrENdcAHo=.8239a95e-57c5-43ca-862f-4b86590d7719@github.com>
Message-ID: <4vKLuq55YhdfWjabTyFQi1qH0IeCsSFqtf0wadrdSGU=.c31e1f42-3dbd-4e87-824f-7cad1f50b99f@github.com>

On Thu, 3 Jun 2021 19:24:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode.

This pull request has now been integrated.

Changeset: 68ac871b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/68ac871b6254cfb55b9ca9da173c9ca1b05f0020
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8268189: ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode

Reviewed-by: mikael

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

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

From xliu at openjdk.java.net  Thu Jun  3 20:12:00 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 20:12:00 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v8]
In-Reply-To: <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
Message-ID: <RHgE-xgOhCfpuVfdBs4nGqJHhBcdcCgpEWwvPY80nIU=.cf34303d-1367-4c28-8d6e-dbdd53b5f516@github.com>

On Thu, 3 Jun 2021 09:06:02 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back to the basic bugfix and remove AsyncLogGtest.java from ProblemList.

David helped me to verify the latest patch using tier1~7.

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

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

From xliu at openjdk.java.net  Thu Jun  3 20:16:04 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 3 Jun 2021 20:16:04 GMT
Subject: RFR: JDK-8268018: remove dead code in commitLimitter
In-Reply-To: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
References: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
Message-ID: <tM3B2XKVZDXzf2539dt9-dD_apDfpQgVCWwCFGVXtpM=.2585a791-ca09-44e0-ba99-61b7f2162a21@github.com>

On Thu, 3 Jun 2021 01:56:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

> it's trivial cleanup to remove some dead code.

LGTM.

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

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

From minqi at openjdk.java.net  Thu Jun  3 21:11:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 3 Jun 2021 21:11:56 GMT
Subject: RFR: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
In-Reply-To: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
References: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
Message-ID: <hnx2ot4SbWwD1ly9WkJjrV9A8OsOm5GchPpbwaPuOjw=.ef3e3198-cc30-4857-be22-06fdb200a312@github.com>

On Thu, 3 Jun 2021 16:34:34 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for disabling the `VerifyDependencies` option when running the CDS MethodHandle tests with debug build. It reduces the time required for running the tests a lot.
> e.g. total time for running the `appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` test with debug build:
> before 489.102s
> after 62.721s
> 
> The patch passed tier1 and tier2 tests.

I would like the common code put in some Util class, so just a call to the function to get the Opt String. how about put the code in CDSTestUtils.java?

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

Changes requested by minqi (Reviewer).

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

From minqi at openjdk.java.net  Thu Jun  3 21:26:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 3 Jun 2021 21:26:56 GMT
Subject: RFR: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
In-Reply-To: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
References: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
Message-ID: <qi89eCzBDs3jxyYomjES5Pj-BlS0RKD2vQRUaAP8PMI=.b09bc0f9-234c-44f7-aa3d-4a52dff87890@github.com>

On Thu, 3 Jun 2021 16:34:34 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for disabling the `VerifyDependencies` option when running the CDS MethodHandle tests with debug build. It reduces the time required for running the tests a lot.
> e.g. total time for running the `appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` test with debug build:
> before 489.102s
> after 62.721s
> 
> The patch passed tier1 and tier2 tests.

Then it is OK to me.

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

Marked as reviewed by minqi (Reviewer).

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

From ccheung at openjdk.java.net  Thu Jun  3 21:26:57 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 3 Jun 2021 21:26:57 GMT
Subject: RFR: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
In-Reply-To: <hnx2ot4SbWwD1ly9WkJjrV9A8OsOm5GchPpbwaPuOjw=.ef3e3198-cc30-4857-be22-06fdb200a312@github.com>
References: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
 <hnx2ot4SbWwD1ly9WkJjrV9A8OsOm5GchPpbwaPuOjw=.ef3e3198-cc30-4857-be22-06fdb200a312@github.com>
Message-ID: <1XN9HipRQzDuU2V9gbV5nCVYhzugC5te6HjBmQT41OI=.389f7f2c-480a-42d3-835f-48f7e9a4ce72@github.com>

On Thu, 3 Jun 2021 21:09:09 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> I would like the common code put in some Util class, so just a call to the function to get the Opt String. how about put the code in CDSTestUtils.java?

Thanks for taking a look.
Only CDS MethodHandles tests are disabling the option. Also note that the only changes are in those sh scripts. The java source are generated from the script. We can put the code in CDSTestUtils.java in the future if more tests require disabling the option.

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

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

From ccheung at openjdk.java.net  Thu Jun  3 22:59:59 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 3 Jun 2021 22:59:59 GMT
Subject: Integrated: 8268095: CDS MethodHandle tests should add
 -XX:-VerifyDependencies
In-Reply-To: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
References: <EigLnlhg0cnTMLECxFAg_Wj_9oZd2ZMob_Nba2jDrgw=.d95a3d27-1b68-44b1-925e-ee4a2e933b5c@github.com>
Message-ID: <5-rfUj9uZp5MnJHJctgkXyWcJEWwW2s7XtJwMT9a8ZY=.54b989b0-6be7-492f-a139-adee5320054f@github.com>

On Thu, 3 Jun 2021 16:34:34 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for disabling the `VerifyDependencies` option when running the CDS MethodHandle tests with debug build. It reduces the time required for running the tests a lot.
> e.g. total time for running the `appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` test with debug build:
> before 489.102s
> after 62.721s
> 
> The patch passed tier1 and tier2 tests.

This pull request has now been integrated.

Changeset: 516e60a7
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/516e60a7ee3072cb3a311432257fab86dd622a48
Stats:     91 lines in 14 files changed: 70 ins; 0 del; 21 mod

8268095: CDS MethodHandle tests should add -XX:-VerifyDependencies

Reviewed-by: iklam, minqi

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

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

From darcy at openjdk.java.net  Fri Jun  4 00:07:32 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Jun 2021 00:07:32 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v2]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <F5OHwj4qDKm-RHroYQzOzHWxdJEKTLN5jSr6wyTxXr8=.9acd03fb-2a0b-4a06-a1c2-203d05ae5153@github.com>

> 8267630: Start of release updates for JDK 18

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 12 additional commits since the last revision:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/388f8dae...e584c467

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4175/files
  - new: https://git.openjdk.java.net/jdk/pull/4175/files/9c7c88bf..e584c467

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

  Stats: 428395 lines in 342 files changed: 426299 ins; 917 del; 1179 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

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

From dholmes at openjdk.java.net  Fri Jun  4 01:06:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 4 Jun 2021 01:06:56 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <zJnLEV0T_c0sXpLMfRwhUasKZLo9mkTUJz0qybBB4do=.553438aa-e150-474c-a7d7-12a4255b32fe@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

I wonder if I could entice any of our Microsoft contributors to give this a technical review (even if not Reviewers) - @luhenry ?

Thanks

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

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

From iignatyev at openjdk.java.net  Fri Jun  4 02:25:01 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 4 Jun 2021 02:25:01 GMT
Subject: RFR: 8267917: mark hotspot containers tests which ignore external
 VM flags
In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
Message-ID: <RdtAbeTbnmsnDXZzXPN9metRwd6yySabiwIgUJy0rYQ=.7112b4b8-70c4-4cdf-9c9b-6c08711e5c02@github.com>

On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags?
> 
> attn: @mseledts
> 
> Cheers,
> -- Igor

Thanks, Harold.

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

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

From iignatyev at openjdk.java.net  Fri Jun  4 02:25:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 4 Jun 2021 02:25:02 GMT
Subject: Integrated: 8267917: mark hotspot containers tests which ignore
 external VM flags
In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>
Message-ID: <mwR53kCh5uHBnP62d04QnSjqKyFm1jCJxT9CfSdxffw=.2c8aef28-7f98-4970-b39e-337c0efac01b@github.com>

On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags?
> 
> attn: @mseledts
> 
> Cheers,
> -- Igor

This pull request has now been integrated.

Changeset: edca245d
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/edca245d5a5f4b43ac853b0c27551a8da2c20309
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8267917: mark hotspot containers tests which ignore external VM flags

Reviewed-by: mseledtsov, hseigel

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

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

From darcy at openjdk.java.net  Fri Jun  4 04:47:22 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Jun 2021 04:47:22 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v3]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <ppBGiNMJsCxk1vBXsOvxvT2vBp4SeY7PPvm7-E7qn80=.870f361f-f23a-406d-bd20-1eae6d7bbf4f@github.com>

> 8267630: Start of release updates for JDK 18

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 13 additional commits since the last revision:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/662de459...fc4d8725

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4175/files
  - new: https://git.openjdk.java.net/jdk/pull/4175/files/e584c467..fc4d8725

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

  Stats: 112 lines in 5 files changed: 10 ins; 50 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

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

From iklam at openjdk.java.net  Fri Jun  4 06:43:16 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 4 Jun 2021 06:43:16 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
 [v3]
In-Reply-To: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
Message-ID: <Z1H-0WEOkFp9Uv64I5WuFIBRNUT8_RejYISuw74xUEY=.89b34d83-52d3-4c4b-a75d-09271cc1c2e4@github.com>

> During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.
> 
> The fix:
> 
> (1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`
> 
> (2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.
> 
> Testing -- Mach5 tiers 1-4 in progress

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

  @calvinccheung comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4322/files
  - new: https://git.openjdk.java.net/jdk/pull/4322/files/e624e1f1..391833dc

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

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

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

From iklam at openjdk.java.net  Fri Jun  4 06:43:16 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 4 Jun 2021 06:43:16 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
 [v2]
In-Reply-To: <WFlg-2K0rsXLXp-tLpjETvoEAEflylvlz0tbqa1o4G8=.c73674c6-4892-43c0-92e6-ae478ea3124b@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
 <uQuxUGHlDoprOQXQNoHhfXjX1uUdJdaqasUUSUyNTMo=.8c054395-483d-41d0-90a7-e0f29fa68efe@github.com>
 <WFlg-2K0rsXLXp-tLpjETvoEAEflylvlz0tbqa1o4G8=.c73674c6-4892-43c0-92e6-ae478ea3124b@github.com>
Message-ID: <WonNh9LMi-6V9IS9mpdz-38CKprvbE-7-I2So13Y0OI=.1aab0986-94a9-487c-877d-417d94eeeaad@github.com>

On Thu, 3 Jun 2021 05:08:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Looks good. In systemDictionaryShared.cpp
> 
> `432 assert(DumpTimeTable_lock->owned_by_self(), "sanity");`
> 
> Can the above be changed to `assert_lock_strong(DumpTimeTable_lock);`?

Hi Calvin, thanks for the review. I've changed it as you suggested. This makes the code more consistent.

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

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

From lzang at openjdk.java.net  Fri Jun  4 07:44:28 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 4 Jun 2021 07:44:28 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v26]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <GjdD3H61vbnFKxomlYWQ3BnRy7cjWbUtXD7KfyKmB0A=.a8c40bb6-0cd2-491b-a265-d3add20dc61d@github.com>

> 8252842: Extend jmap to support parallel heap dump

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

 - Merge branch 'master' into par-dump
 - fix build issue after rebase and fix one issue
 - Merge branch 'master'
 - Merge branch 'master' into pd
 - update copyright info
 - Merge branch 'master' into par-dump
 - undo JMap.java
 - code refine and typo fix
 - Merge branch 'master' into par-dump
 - refine with several fix
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/3025f059...6aee4a47

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

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

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

From rehn at openjdk.java.net  Fri Jun  4 08:49:00 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 4 Jun 2021 08:49:00 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJYTThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
 <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
 <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJY
 TThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>
Message-ID: <k8KxE-V_7Tl7LLx-di6Oht3Nz1oZYsQiaYyBWnDJkfI=.97fe372f-b257-45b2-89be-c34e0fc2c1db@github.com>

On Thu, 3 Jun 2021 16:56:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Maybe it should be added in the comment that the fence is also used to prevent removing of the operation to float above marking the operation as completed so we keep the invariant: "If the handshake operation is not completed it must be on at least one queue".
>
> I still think we can keep the previous memory_order_release order, but if this stricter order makes it easier to read for others then I'm okay.

Added comment.

But that would be relying on implementation details of a generic queue.
This would be a perfectly fine change-set:

diff --git a/src/hotspot/share/utilities/filterQueue.inline.hpp b/src/hotspot/share/utilities/filterQueue.inline.hpp
index 2fa199f2b04..ecb13e57db7 100644
--- a/src/hotspot/share/utilities/filterQueue.inline.hpp
+++ b/src/hotspot/share/utilities/filterQueue.inline.hpp
@@ -94 +94 @@ E FilterQueue<E>::pop(MATCH_FUNC& match_func) {
-      if (Atomic::cmpxchg(&_first, match, match->_next) == match) {
+      if (Atomic::cmpxchg(&_first, match, match->_next, memory_order_relaxed) == match) {



CAS will happened after we load _first, since it's loaded with acquire, but _both_ operation may float above decrement!

Now handshake will break because it would be using a undocumented side affect.
If we are removing any ordering, we should remove it where it is not needed. (the CAS)
Not the other way around!

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

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

From rehn at openjdk.java.net  Fri Jun  4 10:24:36 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 4 Jun 2021 10:24:36 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v4]
In-Reply-To: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
Message-ID: <kBjVCF2slvaAYvmVRhGIQJQVcSvF2y0L9Jmm7N77jzQ=.40f6ae8d-543a-4a42-bbed-80ee0a5ac68a@github.com>

> Please consider this change-set which address the issue on hand.
> 
> I identified two problems:
> 
> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
> Fixed by leaving the handshakee being processed in queue until completed.
> And remove looping, since if ever the queue is empty the handshakee may processed.
> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
> 
> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
> 
> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
> Fixed by adding a loadload.
> 
> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
> (real reprod ~1/400 with increased test time)
> If we are updating the poll there should not be an active handshaker.
> The above fixed the issue.
> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
> 
> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
> 
> Passes stressing relevant test on aarch64 and t1-7.
> 
> Thanks, Robbin

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

 - Added comment
 - Small review updates
 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Small update
 - Merge branch 'master' into handshakee
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3973/files
  - new: https://git.openjdk.java.net/jdk/pull/3973/files/d5028125..40b5a162

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

  Stats: 26096 lines in 914 files changed: 4507 ins; 19790 del; 1799 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3973.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973

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

From rehn at openjdk.java.net  Fri Jun  4 10:24:37 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 4 Jun 2021 10:24:37 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <xjcNh2QHobv9e7sJ6BA-fLG2QER63VWmqpfPMPBps1k=.aa0cdcab-b9ca-41b4-89da-cf6878c37f7e@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <xjcNh2QHobv9e7sJ6BA-fLG2QER63VWmqpfPMPBps1k=.aa0cdcab-b9ca-41b4-89da-cf6878c37f7e@github.com>
Message-ID: <fPrFbpn9BWtjmN02amE_npm0PQVNP1qaqq7RqIimnbk=.b6f45459-8104-4a14-bd4d-1839ff448843@github.com>

On Thu, 3 Jun 2021 16:03:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I've re-reviewed v02 and this time I used the full webrev. It was much
> easier to wrap my head around this time. It could also be because I'm
> re-reviewing much earlier in the day. :-)

Good, thanks! Now there is a small update.

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

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

From rehn at openjdk.java.net  Fri Jun  4 10:32:43 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 4 Jun 2021 10:32:43 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v5]
In-Reply-To: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
Message-ID: <lKq8sB9bfu5XA9x9Os-TM5ouqRwDAMos27dlm5KWfYc=.e2e10f1b-e072-4473-a2e8-14e7d6ef6772@github.com>

> Please consider this change-set which address the issue on hand.
> 
> I identified two problems:
> 
> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
> Fixed by leaving the handshakee being processed in queue until completed.
> And remove looping, since if ever the queue is empty the handshakee may processed.
> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
> 
> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
> 
> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
> Fixed by adding a loadload.
> 
> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
> (real reprod ~1/400 with increased test time)
> If we are updating the poll there should not be an active handshaker.
> The above fixed the issue.
> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
> 
> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
> 
> Passes stressing relevant test on aarch64 and t1-7.
> 
> Thanks, Robbin

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

 - Merge branch 'master' into handshakee
 - Added comment
 - Small review updates
 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Small update
 - Merge branch 'master' into handshakee
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3973/files
  - new: https://git.openjdk.java.net/jdk/pull/3973/files/40b5a162..b0b22231

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

  Stats: 454863 lines in 1491 files changed: 443091 ins; 7464 del; 4308 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3973.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973

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

From mgronlun at openjdk.java.net  Fri Jun  4 15:39:08 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 4 Jun 2021 15:39:08 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left >=
 right) failed: avoid underflow
Message-ID: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>

This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 

The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.

Testing: tier1, tier2, tier6, tier8

Thanks
Markus

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

Commit messages:
 - comment
 - Workaround JDK-8260046

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

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

From ccheung at openjdk.java.net  Fri Jun  4 15:41:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 4 Jun 2021 15:41:58 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
 [v3]
In-Reply-To: <Z1H-0WEOkFp9Uv64I5WuFIBRNUT8_RejYISuw74xUEY=.89b34d83-52d3-4c4b-a75d-09271cc1c2e4@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
 <Z1H-0WEOkFp9Uv64I5WuFIBRNUT8_RejYISuw74xUEY=.89b34d83-52d3-4c4b-a75d-09271cc1c2e4@github.com>
Message-ID: <DDTLCdKOS3tKL5Tl_EcaRYLas3lFX9xKJW8rRtaUkRg=.0f510f2a-9c23-4538-b582-854771d04fc0@github.com>

On Fri, 4 Jun 2021 06:43:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.
>> 
>> The fix:
>> 
>> (1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`
>> 
>> (2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.
>> 
>> Testing -- Mach5 tiers 1-4 in progress
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comments

Marked as reviewed by ccheung (Reviewer).

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

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

From pchilanomate at openjdk.java.net  Fri Jun  4 18:18:02 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 4 Jun 2021 18:18:02 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <k8KxE-V_7Tl7LLx-di6Oht3Nz1oZYsQiaYyBWnDJkfI=.97fe372f-b257-45b2-89be-c34e0fc2c1db@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
 <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
 <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJY
 TThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>
 <k8KxE-V_7Tl7LLx-di6Oht3Nz1oZYsQiaYyBWnDJkfI=.97fe372f-b257-45b2-89be-c34e0fc2c1db@github.com>
Message-ID: <J4KDyjpj3HWMsdCldHrY6rAkTcrv3G6q5dGLLDS3-LA=.3c47d259-d7e2-4592-9abd-082aec2d90ee@github.com>

On Fri, 4 Jun 2021 08:44:54 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> I still think we can keep the previous memory_order_release order, but if this stricter order makes it easier to read for others then I'm okay.
>
> Added comment.
> 
> But that would be relying on implementation details of a generic queue.
> This would be a perfectly fine change-set:
> 
> diff --git a/src/hotspot/share/utilities/filterQueue.inline.hpp b/src/hotspot/share/utilities/filterQueue.inline.hpp
> index 2fa199f2b04..ecb13e57db7 100644
> --- a/src/hotspot/share/utilities/filterQueue.inline.hpp
> +++ b/src/hotspot/share/utilities/filterQueue.inline.hpp
> @@ -94 +94 @@ E FilterQueue<E>::pop(MATCH_FUNC& match_func) {
> -      if (Atomic::cmpxchg(&_first, match, match->_next) == match) {
> +      if (Atomic::cmpxchg(&_first, match, match->_next, memory_order_relaxed) == match) {
> 
> 
> 
> CAS will happened after we load _first, since it's loaded with acquire, but _both_ operation may float above decrement!
> 
> Now handshake will break because it would be using a undocumented side affect.
> If we are removing any ordering, we should remove it where it is not needed. (the CAS)
> Not the other way around!

As long as we have a release() fence after the handshake closure the reordering of decrementing _pending_threads and removing the operation from the queue shouldn't matter since the target doesn't read _pending_threads.

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

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

From xliu at openjdk.java.net  Fri Jun  4 21:08:23 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 4 Jun 2021 21:08:23 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
Message-ID: <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>

> 8268165: AsyncLogging will crash if rotate() fails

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

 - Merge branch 'master' into JDK-8268165
 - 8268165: AsyncLogging will crash if rotate() fails

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4332/files
  - new: https://git.openjdk.java.net/jdk/pull/4332/files/8e6cb1c8..20c08df6

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

  Stats: 429538 lines in 359 files changed: 426694 ins; 1512 del; 1332 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4332.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4332/head:pull/4332

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

From rehn at openjdk.java.net  Fri Jun  4 22:49:01 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 4 Jun 2021 22:49:01 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <J4KDyjpj3HWMsdCldHrY6rAkTcrv3G6q5dGLLDS3-LA=.3c47d259-d7e2-4592-9abd-082aec2d90ee@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
 <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
 <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJY
 TThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>
 <k8KxE-V_7Tl7LLx-di6Oht3Nz1oZYsQiaYyBWnDJkfI=.97fe372f-b257-45b2-89be-c34e0fc2c1db@github.com>
 <J4KDyjpj3HWMsdCldHrY6rAkTcrv3G6q5dGLLDS3-LA=.3c47d259-d7e2-4592-9abd-082aec2d90ee@github.com>
Message-ID: <3fhWHR3YaOU0XDbH0UTx6xnToWKNwGfPdZkyxYxgiyg=.c5e34807-5f52-4dbc-9093-bed95d79a329@github.com>

On Fri, 4 Jun 2021 18:15:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Added comment.
>> 
>> But that would be relying on implementation details of a generic queue.
>> This would be a perfectly fine change-set:
>> 
>> diff --git a/src/hotspot/share/utilities/filterQueue.inline.hpp b/src/hotspot/share/utilities/filterQueue.inline.hpp
>> index 2fa199f2b04..ecb13e57db7 100644
>> --- a/src/hotspot/share/utilities/filterQueue.inline.hpp
>> +++ b/src/hotspot/share/utilities/filterQueue.inline.hpp
>> @@ -94 +94 @@ E FilterQueue<E>::pop(MATCH_FUNC& match_func) {
>> -      if (Atomic::cmpxchg(&_first, match, match->_next) == match) {
>> +      if (Atomic::cmpxchg(&_first, match, match->_next, memory_order_relaxed) == match) {
>> 
>> 
>> 
>> CAS will happened after we load _first, since it's loaded with acquire, but _both_ operation may float above decrement!
>> 
>> Now handshake will break because it would be using a undocumented side affect.
>> If we are removing any ordering, we should remove it where it is not needed. (the CAS)
>> Not the other way around!
>
> As long as we have a release() fence after the handshake closure the reordering of decrementing _pending_threads and removing the operation from the queue shouldn't matter since the target doesn't read _pending_threads.

"release operation: no reads or writes in the current thread can be reordered after this store."

But stores happened after this store may be reordered before. Which means the removal might happen even before the handshake operation was executed.

So we need to stop the store ("the relaxed CAS") from floating above the dec.

Dec with rel+acq gives: "No memory reads or writes in the current thread can be reordered before or after this store."

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

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

From duke at openjdk.java.net  Sat Jun  5 11:10:04 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 5 Jun 2021 11:10:04 GMT
Subject: Withdrawn: 8264482: container info misleads on non-container
 environment
In-Reply-To: <fYMipmrhWIaVF7laDK7KGSmqmbvsRujLh0bkxSrSQts=.5e74eb08-4d30-4a79-9ec4-51fd6b007115@github.com>
References: <fYMipmrhWIaVF7laDK7KGSmqmbvsRujLh0bkxSrSQts=.5e74eb08-4d30-4a79-9ec4-51fd6b007115@github.com>
Message-ID: <jzdeMsw8DW1TFr-ilMq7uF_WAjhuSR8etkS8nR2mdMQ=.d84e9cc6-b06c-44c4-960d-657b30c02398@github.com>

On Wed, 31 Mar 2021 06:24:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> hs_err log and `VM.info` dcmd shows cgroup information as container information even though the process run on non-container environment as following.
> 
> 
> container (cgroup) information:
> container_type: cgroupv2
> cpu_cpuset_cpus: not supported
> cpu_memory_nodes: not supported
> active_processor_count: 4
> cpu_quota: not supported
> cpu_period: not supported
> cpu_shares: not supported
> memory_limit_in_bytes: unlimited
> memory_and_swap_limit_in_bytes: unlimited
> memory_soft_limit_in_bytes: unlimited
> memory_usage_in_bytes: 164163584
> memory_max_usage_in_bytes: not supported
> 
> 
> We can use cgroup outside of container, so it is useful to show. However cgroup is different from container. We should distinguish them.
> And also it is useful if we can see container runtime in this section. So I added it. We can see following contents in this section after this change.
> 
> 
> cgroup information:
> cgroup_type: cgroupv2
> container runtime: podman
> cpu_cpuset_cpus: not supported
> cpu_memory_nodes: not supported
> active_processor_count: 4
> cpu_quota: not supported
> cpu_period: not supported
> cpu_shares: not supported
> memory_limit_in_bytes: unlimited
> memory_and_swap_limit_in_bytes: unlimited
> memory_soft_limit_in_bytes: unlimited
> memory_usage_in_bytes: 256176128
> memory_max_usage_in_bytes: not supported
> 
> 
> In case of systemd, it checks PID (PID 1 or not) and `$container` in PID 1. We should check them to know the JVM runs on the container or not.
> 
> https://github.com/systemd/systemd/blob/68337e55f62cf49b7bdfb73dc5662e23b0ea17fa/src/basic/virt.c#L619

This pull request has been closed without being integrated.

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:21:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:21:06 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
Message-ID: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>

A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

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

Commit messages:
 - 8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC

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

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

From iklam at openjdk.java.net  Sat Jun  5 15:25:01 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 5 Jun 2021 15:25:01 GMT
Subject: RFR: 8268139: CDS ArchiveBuilder may reference unloaded classes
 [v3]
In-Reply-To: <deAKHyi_c_oO70jI_gemQiAsd8LVy6Y5ewOTapUrG_8=.a1c90414-b8f9-4dd7-b823-28ae0f2cd866@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
 <deAKHyi_c_oO70jI_gemQiAsd8LVy6Y5ewOTapUrG_8=.a1c90414-b8f9-4dd7-b823-28ae0f2cd866@github.com>
Message-ID: <04lGPUF51BClxlPW83EeLMVq2rHDSmV4j2vFtfG_xkA=.14aea225-377e-4bee-973b-0b0d1c616b9a@github.com>

On Wed, 2 Jun 2021 22:26:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @calvinccheung comments
>
> Except a minor comment, this looks good.

Thanks @coleenp and @calvinccheung for the review

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

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

From iklam at openjdk.java.net  Sat Jun  5 15:25:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 5 Jun 2021 15:25:02 GMT
Subject: Integrated: 8268139: CDS ArchiveBuilder may reference unloaded classes
In-Reply-To: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
References: <BSo4BIDmpXk_nvzV-m_ixWPSkj9OgMwaAXG6ldKnqJ4=.e6a415d5-a91f-4585-a059-986567167229@github.com>
Message-ID: <teYHW5KBqzAX050sLz4E_4iTsQIryT2M72An36I6C6k=.0f66dd5c-6780-47b9-91db-038296994209@github.com>

On Wed, 2 Jun 2021 21:31:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During CDS dump, we enter a safepoint (e.g., `VM_PopulateDynamicDumpSharedSpace`) and run `ArchiveBuilder::gather_source_objs()` to collect all classes to be dumped. However, some of these classes may belong to custom class loaders that are no longer alive. While we are still inside the safepoint, concurrent GC operations may free these class loaders (see https://github.com/openjdk/jdk/pull/4286). Thus `ArchiveBuilder` may end up referencing unloaded classes.
> 
> The fix:
> 
> (1) Add a class `k` to ArchiveBuilder only if `k->class_loader_data()->is_alive()`
> 
> (2) All the classes added to `ArchiveBuilder` are taken from `DumpTimeSharedClassTable`. When a class is loaded, it's added to this table. When a class is unloaded, it's removed from this table (via `SystemDictionaryShared::remove_dumptime_info`). This table is protected by `DumpTimeTable_lock`. To make sure that this table is not changed during the CDS safepoint, we grab this lock before calling `ArchiveBuilder::gather_source_objs()`, and release this lock only when the CDS dump is finished. As a result, in step (1) above, when we call `k->class_loader_data()->is_alive()`, we are sure that `k` itself has not been deallocated and is still a valid pointer.
> 
> Testing -- Mach5 tiers 1-4 in progress

This pull request has now been integrated.

Changeset: 91f9adc5
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91f9adc5f55b42d30e46d99e22a8d0567fa5c146
Stats:     23 lines in 4 files changed: 15 ins; 0 del; 8 mod

8268139: CDS ArchiveBuilder may reference unloaded classes

Reviewed-by: coleenp, ccheung

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:41:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:41:00 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
Message-ID: <yVy65pA-xEcHwGMDXiwrGntGTAWMy6NRa96dCEygHW4=.406b0f3e-1c07-4ca6-a8c0-275ce7fc5a41@github.com>

On Fri, 4 Jun 2021 15:30:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
> 
> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
> 
> Testing: tier1, tier2, tier6, tier8
> 
> Thanks
> Markus

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From rriggs at openjdk.java.net  Sat Jun  5 15:51:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sat, 5 Jun 2021 15:51:02 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <UX08aKmG8dBZ1k9N3PtYvssfVNDkTk3sp4DBjugBYAA=.9dae0353-8768-44ba-ab9d-9da29effde3a@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

Marked as reviewed by rriggs (Reviewer).

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:51:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:51:02 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <UX08aKmG8dBZ1k9N3PtYvssfVNDkTk3sp4DBjugBYAA=.9dae0353-8768-44ba-ab9d-9da29effde3a@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
 <UX08aKmG8dBZ1k9N3PtYvssfVNDkTk3sp4DBjugBYAA=.9dae0353-8768-44ba-ab9d-9da29effde3a@github.com>
Message-ID: <WUi52G6-Botda03dxXpnL6Qm9iSTI1Ziz_oQW8XWfq4=.59ac2118-e00d-44c2-8dd7-b67c217f1805@github.com>

On Sat, 5 Jun 2021 15:47:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the review!

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:54:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:54:01 GMT
Subject: Integrated: 8268286: ProblemList serviceability/sa/TestJmapCore.java
 on linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <06RCOXEMcxl_aEzlj-GWMNda5Zu9Z8wFJ6G729CqWPU=.03a9340d-47db-4493-a9e1-8940dc6542c6@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

This pull request has now been integrated.

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

8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC

Reviewed-by: rriggs

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

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

From clanger at openjdk.java.net  Sat Jun  5 15:54:56 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 5 Jun 2021 15:54:56 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
 <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
Message-ID: <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>

On Wed, 2 Jun 2021 20:49:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> SInce JDK-8263066 suggests more enhancements, it may be worth keeping it to track the remaining ones.

No, the issue we're trying to solve with JDK-8263066 is basically the same as with JDK-8267666, so we'll close it. There's also JDK-8200579 which could be closed then.

> @AlanBateman The patch does not do anything special to the named pipe use-case, although makes it possible. Do you suggest removing mentions of the use-case from the CSR? Otherwise, what concerns could I address?

I would suggest to change the CSR to use "overwrite" but other than that, it seems fine. Let's wait what Alan has to say but that would be my thinking.

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

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

From darcy at openjdk.java.net  Sat Jun  5 18:42:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 5 Jun 2021 18:42:37 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v4]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <CwGWV6oh22edpW-WMk6Ad20JtavdEYYCqD4aNdhOVU8=.7e05650d-a36e-4db5-893d-2d9396007e04@github.com>

> 8267630: Start of release updates for JDK 18

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 15 additional commits since the last revision:

 - Update symbols for JDK 17 b25.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/5aafa154...f926c1bc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4175/files
  - new: https://git.openjdk.java.net/jdk/pull/4175/files/fc4d8725..f926c1bc

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

  Stats: 2678 lines in 127 files changed: 1537 ins; 898 del; 243 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

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

From akozlov at openjdk.java.net  Sat Jun  5 18:45:58 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sat, 5 Jun 2021 18:45:58 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
 <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
 <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
Message-ID: <mAoqp1NdXzVBDhrzt687fMRMIDUW_0VKlKH8xFLdS24=.b090b31e-eda5-43c0-bf6c-936a7ae5abe4@github.com>

On Sat, 5 Jun 2021 15:51:49 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I would suggest to change the CSR to use "overwrite" but other than that, it seems fine.

Right, thanks! Now it is fixed, CSR uses "overwrite".

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

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

From alanb at openjdk.java.net  Sun Jun  6 05:34:17 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 6 Jun 2021 05:34:17 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
 <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
 <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
Message-ID: <6uEFztVTs7AM8Nw6PaVezGdkLF6qXrnFPzMKGi00I2w=.5d9720e1-92aa-4df9-9b85-e0c3c188166f@github.com>

On Sat, 5 Jun 2021 15:51:49 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I would suggest to change the CSR to use "overwrite" but other than that, it seems fine. Let's wait what Alan has to say but that would be my thinking.

Using "-overwrite" to opt-in to overwrite an existing file looks good to me.

The CSR still has wording to suggest that the new option is also to support socket/other files. I read the PR as just the overwrite existing file case. If so then maybe those (two) sentences can be changed in the CSR to make it clearer.

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

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

From clanger at openjdk.java.net  Sun Jun  6 06:19:04 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sun, 6 Jun 2021 06:19:04 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <8JTsTdzmZwZCEuJ7BPBgs1XSRD2OjYC01U8WqUqWJ5k=.3f7100d6-02ee-436e-b0da-dd707ba983d4@github.com>

On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows flags (although complied fine)

Thanks Alan for commenting on that one.

> The CSR still has wording to suggest that the new option is also to support socket/other files. I read the PR as just the overwrite existing file case. If so then maybe those (two) sentences can be changed in the CSR to make it clearer.

I think it's ok to mention the use-cases like pipe support which is something that'll be enabled by this change. But feel free to remove it. I've marked the CSR as reviewed from my end.

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

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

From akozlov at openjdk.java.net  Sun Jun  6 08:53:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 6 Jun 2021 08:53:19 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>

On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows flags (although complied fine)

Thanks for the comments! Indeed, the change is about the "overwrite" option only. The CSR describes why the option is necessary, and sockets and pipes are just examples. I have rephrased CSR to be more explicit about the option, but not examples.

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

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

From clanger at openjdk.java.net  Sun Jun  6 09:36:06 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sun, 6 Jun 2021 09:36:06 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
 <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>
Message-ID: <aonUhmydCaajEb6bMfsGE6NjhFjrd-9R9j6ZcLQWM8w=.7294fa14-9029-4ff8-b54a-376a67e95d44@github.com>

On Sun, 6 Jun 2021 08:50:22 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Thanks for the comments! Indeed, the change is about the "overwrite" option only. The CSR describes why the option is necessary, and sockets and pipes are just examples. I have rephrased CSR to be more explicit about the option, but not examples.

Perfect, looks good to me.

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

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

From xliu at openjdk.java.net  Sun Jun  6 22:40:09 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 6 Jun 2021 22:40:09 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
Message-ID: <4WqmlFmdki7laJaKnIsA_8-f0tI6UBkUB7RHpwOZidM=.807f9326-1d78-47e3-85a8-07a180099758@github.com>

On Fri, 4 Jun 2021 21:08:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8268165
>  - 8268165: AsyncLogging will crash if rotate() fails

hi, @YaSuenag, 
Could you take a look at this? It's an error-handling patch. 

thanks,
--lx

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

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

From ysuenaga at openjdk.java.net  Mon Jun  7 00:04:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 7 Jun 2021 00:04:04 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
Message-ID: <ctTYNwUMaUpy8RdCnnH8azrXLudk9Kat95meWNa-B1s=.27211a69-c478-4de3-a3d9-5d9263a4bc11@github.com>

On Fri, 4 Jun 2021 21:08:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8268165
>  - 8268165: AsyncLogging will crash if rotate() fails

Looks good.

I wonder why we use semaphore instead of mutex for `_rotation_semaphore`, but it's not yours.

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

Marked as reviewed by ysuenaga (Reviewer).

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

From xliu at openjdk.java.net  Mon Jun  7 00:45:01 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Jun 2021 00:45:01 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <ctTYNwUMaUpy8RdCnnH8azrXLudk9Kat95meWNa-B1s=.27211a69-c478-4de3-a3d9-5d9263a4bc11@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
 <ctTYNwUMaUpy8RdCnnH8azrXLudk9Kat95meWNa-B1s=.27211a69-c478-4de3-a3d9-5d9263a4bc11@github.com>
Message-ID: <XKYOwAR9A4XjDLSZSqsH0zru3xbrv-8m4XqY1VEo6t4=.cdcffea3-8960-4915-ac94-6b3e9ac91fbf@github.com>

On Mon, 7 Jun 2021 00:00:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Looks good.
> 
> I wonder why we use semaphore instead of mutex for `_rotation_semaphore`, but it's not yours.

Thanks for reviewing it. 

I can try to answer this.  Synchronous logging writing may happen anywhere and anytime. 
hotspot's mutex requires Thread::current().  We can't assume that in very early stage or very late stage, or it will fail this assertion. 

  assert(current != NULL, "Thread::current() called on detached thread");


eg. this logsite is invoked after `delete thread;`.  
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/threadSMR.cpp#L1027

Semaphore doesn't have this constraint.

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

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

From ysuenaga at openjdk.java.net  Mon Jun  7 00:51:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 7 Jun 2021 00:51:04 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <XKYOwAR9A4XjDLSZSqsH0zru3xbrv-8m4XqY1VEo6t4=.cdcffea3-8960-4915-ac94-6b3e9ac91fbf@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
 <ctTYNwUMaUpy8RdCnnH8azrXLudk9Kat95meWNa-B1s=.27211a69-c478-4de3-a3d9-5d9263a4bc11@github.com>
 <XKYOwAR9A4XjDLSZSqsH0zru3xbrv-8m4XqY1VEo6t4=.cdcffea3-8960-4915-ac94-6b3e9ac91fbf@github.com>
Message-ID: <Fts7_8s3jOMAVoQGAIC_UVbzO0YCQCOzwiWY4sEZkVs=.a507dcf2-f6da-4c9f-9ed3-f7a50386faff@github.com>

On Mon, 7 Jun 2021 00:41:53 GMT, Xin Liu <xliu at openjdk.org> wrote:

> I can try to answer this. Synchronous logging writing may happen anywhere and anytime.
> hotspot's mutex requires Thread::current(). We can't assume that in very early stage or very late stage, or it will fail this assertion.
> 
> ```
>   assert(current != NULL, "Thread::current() called on detached thread");
> ```
> 
> eg. this logsite is invoked after `delete thread;`.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/threadSMR.cpp#L1027
> 
> Semaphore doesn't have this constraint.

Ah, I see. Thanks!

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

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

From mli at openjdk.java.net  Mon Jun  7 01:18:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 7 Jun 2021 01:18:59 GMT
Subject: RFR: JDK-8268018: remove dead code in commitLimitter
In-Reply-To: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
References: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
Message-ID: <VTWOvcTy1qDbW6ydIyCUvQci1QmM2A15vP0jSZUpb5E=.667a1da1-de94-4f0d-a6af-7607a65ea9a4@github.com>

On Thu, 3 Jun 2021 01:56:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

> it's trivial cleanup to remove some dead code.

ping~

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

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

From mli at openjdk.java.net  Mon Jun  7 01:23:02 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 7 Jun 2021 01:23:02 GMT
Subject: RFR: JDK-8267839: trivial mem leak in numa
In-Reply-To: <9tNfLw69ARW81P5xjvOsC_xW_qJAiqBV0xnx64CKRho=.efc078f4-0bdc-4c63-808e-8a7f8963c5ba@github.com>
References: <jdETap6Eo7djsPxIF6rKqZJuAk9V8KWb7AzC-DJJ6iI=.a024d69b-1bbc-418b-9524-9e30e5491012@github.com>
 <9tNfLw69ARW81P5xjvOsC_xW_qJAiqBV0xnx64CKRho=.efc078f4-0bdc-4c63-808e-8a7f8963c5ba@github.com>
Message-ID: <aidoerXFSwWj7kSK9SxyYgcRbc9Z2DgRVhcFBfyH4qs=.e80fb29d-3cd7-42d6-98aa-749a515fedcf@github.com>

On Mon, 31 May 2021 12:09:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> There is a trivial mem leak in numa related code. This patch is to use a stored bitmask* rather than get a new one.
>
> Lgtm. Please wait for a second reviewer, preferably from the runtime team, before pushing this.

@tschatzl @kstefanj Thanks for your review.

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

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

From mli at openjdk.java.net  Mon Jun  7 01:23:03 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 7 Jun 2021 01:23:03 GMT
Subject: Integrated: JDK-8267839: trivial mem leak in numa
In-Reply-To: <jdETap6Eo7djsPxIF6rKqZJuAk9V8KWb7AzC-DJJ6iI=.a024d69b-1bbc-418b-9524-9e30e5491012@github.com>
References: <jdETap6Eo7djsPxIF6rKqZJuAk9V8KWb7AzC-DJJ6iI=.a024d69b-1bbc-418b-9524-9e30e5491012@github.com>
Message-ID: <heqxn_sCfO7WNf5Isw3uD4oqxBoeIuddkj1wrspvIFI=.16f14675-1a79-4c29-8ebd-ca5b0f27e5f9@github.com>

On Thu, 27 May 2021 08:46:00 GMT, Hamlin Li <mli at openjdk.org> wrote:

> There is a trivial mem leak in numa related code. This patch is to use a stored bitmask* rather than get a new one.

This pull request has now been integrated.

Changeset: 95ddf7d6
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/95ddf7d6ada599e57feefca7fa9c6379e6a23523
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8267839: trivial mem leak in numa

Co-authored-by: Shoubing Ma <mashoubing1 at huawei.com>
Reviewed-by: tschatzl, sjohanss

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

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

From jiangli at openjdk.java.net  Mon Jun  7 03:38:14 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Mon, 7 Jun 2021 03:38:14 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData()
Message-ID: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>

This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.

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

Commit messages:
 - JDK-8268088

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

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

From pchilanomate at openjdk.java.net  Mon Jun  7 03:49:00 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 7 Jun 2021 03:49:00 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <3fhWHR3YaOU0XDbH0UTx6xnToWKNwGfPdZkyxYxgiyg=.c5e34807-5f52-4dbc-9093-bed95d79a329@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com>
 <-orYAN9n1kzhY0vFjjMJ6iw4wZDeu1iB__i-dNkJ32w=.51ac2bba-835e-40e4-b3cb-1a98667a009a@github.com>
 <lw9noQ8cidMPRn9H4wYYxpVaMW-PyWKhKvF562vHW0M=.27c24af0-90e3-4200-b641-1bf260a13900@github.com>
 <t9-TfJGrmGqT79LaxYwjj5goyByo-6iGRrGOI0SRd-Y=.a29b74ff-5a52-4b29-b8d3-e38471e445ac@github.com>
 <z8hJd29VOmgvdhkOWkVv68ZKwfm_aZBtLEHuhvEbPD8=.841fa500-1e73-4863-8022-36c47deda412@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
 <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
 <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJY
 TThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>
 <k8KxE-V_7Tl7LLx-di6Oht3Nz1oZYsQiaYyBWnDJkfI=.97fe372f-b257-45b2-89be-c34e0fc2c1db@github.com>
 <J4KDyjpj3HWMsdCldHrY6rAkTcrv3G6q5dGLLDS3-LA=.3c47d259-d7e2-4592-9abd-082aec2d90ee@github.com>
 <3fhWHR3YaOU0XDbH0UTx6xnToWKNwGfPdZkyxYxgiyg=.c5e34807-5f52-4dbc-9093-bed95d79a329@github.com>
Message-ID: <o2GFPbOPZcfXfQlhHasiC8QewbG1lrgar1Tm5WeamUE=.25060f89-3159-4b09-997b-240bb9defaae@github.com>

On Fri, 4 Jun 2021 22:46:08 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As long as we have a release() fence after the handshake closure the reordering of decrementing _pending_threads and removing the operation from the queue shouldn't matter since the target doesn't read _pending_threads.
>
> "release operation: no reads or writes in the current thread can be reordered after this store."
> 
> But stores happened after this store may be reordered before. Which means the removal might happen even before the handshake operation was executed.
> 
> So we need to stop the store ("the relaxed CAS") from floating above the dec.
> 
> Dec with rel+acq gives: "No memory reads or writes in the current thread can be reordered before or after this store."

By release() fence I was referring to the definition in orderAccess (LoadStore | StoreStore), sorry for the confusion, which would be enough to prevent any of those writes to float above the barrier. I now see that dec( ,memory_order_release) might not necessarily provide that though so we would need to use OrderAccess::release() + dec( ,memory_order_relaxed) instead. But I see that using a full fence is probably easier to read. Also by looking at the implementations of dec() for arm32/aarch64 it seems the order parameter is ignored (always full fence) (?), which would defeat the purpose of using release().

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

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

From dholmes at openjdk.java.net  Mon Jun  7 04:23:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Jun 2021 04:23:02 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
Message-ID: <7-zHGAH0Hry7plbKkf3VyGdTWe2jEXDR9RTqc4dFu6Q=.d0ab1405-9190-4865-ae07-21bd183ae58b@github.com>

On Fri, 4 Jun 2021 15:30:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
> 
> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
> 
> Testing: tier1, tier2, tier6, tier8
> 
> Thanks
> Markus

Hi Markus,

So this fix simply unpacks used_bytes() to avoid calling pointer_delta with values that trigger the assertion. But given we see other problems with that assertion ie JDK-8268265, then could it not be that the assertion is in fact the problem? Is the assertion not making a usage assumption that is simply not valid?

Thanks,
David

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

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

From stefank at openjdk.java.net  Mon Jun  7 07:04:03 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 7 Jun 2021 07:04:03 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
Message-ID: <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>

On Fri, 4 Jun 2021 15:30:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
> 
> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
> 
> Testing: tier1, tier2, tier6, tier8
> 
> Thanks
> Markus

This is a race-condition and will potentially fail just the same way the bug in #4224 did. There needs to be at least Atomic::loads of the the variables, or the compiler could convert the loads into multiple loads.

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

Changes requested by stefank (Reviewer).

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

From dholmes at openjdk.java.net  Mon Jun  7 07:47:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Jun 2021 07:47:00 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
Message-ID: <oOIS3GK7ADDGUUi1aP6pfYbTNvhuqTBoBV40g5RAAEY=.69892927-09b9-4abf-8a66-391bc2d96be2@github.com>

On Mon, 7 Jun 2021 07:01:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> This is a race-condition and will potentially fail just the same way the bug in #4224 did. There needs to be at least Atomic::loads of the the variables, or the compiler could convert the loads into multiple loads.

@stefank has explained in the bug report why the assertion is not the issue - thanks. So I have to question the validity of just side-stepping the assertion without trying to fix the broken code. What are the implications of finding these broken invariants in the product code? Do we just report/print an incorrect value?

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

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

From dholmes at openjdk.java.net  Mon Jun  7 07:51:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Jun 2021 07:51:59 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v8]
In-Reply-To: <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
Message-ID: <ulweZG4Y0kbPtNH7ZX1Yc1OQKoJxMXnLHC3LhYa9x1s=.542494de-db98-48eb-9a13-999e09f43082@github.com>

On Thu, 3 Jun 2021 09:06:02 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back to the basic bugfix and remove AsyncLogGtest.java from ProblemList.

Marked as reviewed by dholmes (Reviewer).

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

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

From lzang at openjdk.java.net  Mon Jun  7 07:58:26 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 7 Jun 2021 07:58:26 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v27]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>

> 8252842: Extend jmap to support parallel heap dump

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

 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - fix build issue after rebase and fix one issue
 - Merge branch 'master'
 - Merge branch 'master' into pd
 - update copyright info
 - Merge branch 'master' into par-dump
 - undo JMap.java
 - code refine and typo fix
 - Merge branch 'master' into par-dump
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/908aca29...78c2c763

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

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

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

From xliu at openjdk.java.net  Mon Jun  7 08:10:04 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Jun 2021 08:10:04 GMT
Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator
 was not part of the decorator set specified at creation. [v8]
In-Reply-To: <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
 <PPJ-lzwKeMV3bPnEZ9HAD5hY8Ck_KLJwlmlME2zawPw=.d17bc6d2-c2e9-44f2-b2e1-40d2dc82d285@github.com>
Message-ID: <l_aG_NpwdStJTsEGJyR4X9zqePADY9LffieKs-njFRs=.22219dc1-5d28-4a71-ba1d-0ba8c543f057@github.com>

On Thu, 3 Jun 2021 09:06:02 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The root cause of the intermittent failure is that _decorators in LogDecorations 
>> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
>> Log output via set_log_config(TestLogFileName, "all=off").
>> 
>> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
>> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back to the basic bugfix and remove AsyncLogGtest.java from ProblemList.

Thanks all reviewers!

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

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

From fweimer at openjdk.java.net  Mon Jun  7 08:24:07 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Mon, 7 Jun 2021 08:24:07 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v4]
In-Reply-To: <mtMzHZ5vyhd00iSalcPijHz75Vmu16ghn7zDKkRhWac=.5750824b-a4a6-4090-8e17-59ba50ae3451@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <Q3flGqmZMOG8v8eNDyexJhdeR4PqIgV1WjBQf7r1K24=.b20923c6-1ebf-4ba4-bebc-12a8422d8508@github.com>
 <mN6apL6i8uLLLAF7XYwuarKsi-7ktMD5RZ9U6MeuFMI=.b95c6ca9-a1c8-4143-859f-9bf240e986b2@github.com>
 <HjTMSSSiIUG9BcoWJXn1LSsqG3uCONzlFK3yDkfdzps=.16c4c131-f81a-4ea4-bfed-4ea9e3c1802d@github.com>
 <mtMzHZ5vyhd00iSalcPijHz75Vmu16ghn7zDKkRhWac=.5750824b-a4a6-4090-8e17-59ba50ae3451@github.com>
Message-ID: <OdS6KRs0o1g8PA0-tTGNPP_dkxO_Hr29JJxlfUm-XZc=.aff78d67-0422-4ff0-9c61-ceb21bd6c1e0@github.com>

On Wed, 2 Jun 2021 14:10:36 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > This is not the correct number. It is 269 on both s390 and s390x. (236 is `gettid` on s390x.)
> 
> If this is true, there should be a bug in the libnuma source code [1].
> All my syscall numbers are copied from libnuma code.
> Thanks.
> 
> [1] https://github.com/numactl/numactl/blob/master/syscall.c#L121

Thanks, I have filed an issue: numactl/numactl#110

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

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

From jiefu at openjdk.java.net  Mon Jun  7 08:27:02 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 7 Jun 2021 08:27:02 GMT
Subject: RFR: 8268014: Build failure on SUSE Linux Enterprise Server 11.4
 (s390x) due to 'SYS_get_mempolicy' was not declared [v5]
In-Reply-To: <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
References: <iO-oNl-c7NwxM8RqNeE03h4qw21KVougFpHh_VIF23U=.0f257873-9de0-4a9b-914d-c94c6324a672@github.com>
 <KYgvdLqT-OaAuzJcLhrbk60TtOcR8uOtibuELr8m-rg=.48ab6ec3-9bd0-435e-adf2-3523504787a4@github.com>
Message-ID: <YqWL3CilYguxOi4RHlaPZHf9Qp7YPfVXerFGx1Qz7S8=.8e7e7159-803c-4430-ae05-c29f4278cd96@github.com>

On Wed, 2 Jun 2021 23:08:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the patch which fixes the build failure on SUSE Linux Enterprise Server 11.4 (s390x).
>> 
>> @dholmes-ora had reminded me of this bug in [1].
>> But I missed the fact that ZGC is currently only built on x64 and aarch64.
>> And I'm sorry for this breakage.
>> 
>> The sys_call numbers of get_mempolicy for different platforms are just copied from the libnuma source code [2].
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#discussion_r639708293
>> [2] https://github.com/numactl/numactl/blob/master/syscall.c
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   #ifdef SYS_get_mempolicy in numa_syscall_check

> > > This is not the correct number. It is 269 on both s390 and s390x. (236 is `gettid` on s390x.)
> > 
> > 
> > If this is true, there should be a bug in the libnuma source code [1].
> > All my syscall numbers are copied from libnuma code.
> > Thanks.
> > [1] https://github.com/numactl/numactl/blob/master/syscall.c#L121
> 
> Thanks, I have filed an issue: [numactl/numactl#110](https://github.com/numactl/numactl/issues/110)

Thumbs up.

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

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

From rehn at openjdk.java.net  Mon Jun  7 09:07:09 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 7 Jun 2021 09:07:09 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v6]
In-Reply-To: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
Message-ID: <8yz8b4bqC7aZuAcBC7sFWdL7mTkFc4zDwyAn3Cg-yEU=.089f3a7a-23c8-4e68-aa5c-ffc71d9ee7bd@github.com>

> Please consider this change-set which address the issue on hand.
> 
> I identified two problems:
> 
> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
> Fixed by leaving the handshakee being processed in queue until completed.
> And remove looping, since if ever the queue is empty the handshakee may processed.
> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
> 
> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
> 
> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
> Fixed by adding a loadload.
> 
> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
> (real reprod ~1/400 with increased test time)
> If we are updating the poll there should not be an active handshaker.
> The above fixed the issue.
> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
> 
> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
> 
> Passes stressing relevant test on aarch64 and t1-7.
> 
> Thanks, Robbin

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

 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Added comment
 - Small review updates
 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Small update
 - Merge branch 'master' into handshakee
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3973/files
  - new: https://git.openjdk.java.net/jdk/pull/3973/files/b0b22231..7277d7a6

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

  Stats: 11266 lines in 295 files changed: 8827 ins; 1635 del; 804 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3973.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973

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

From sgehwolf at openjdk.java.net  Mon Jun  7 10:00:58 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 7 Jun 2021 10:00:58 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <z3jJxWuQYLCx6glwzvc83Z65F_HmEyGrTJOBhv4R8lA=.cc34c0a6-5475-4e25-882a-c1696a8022d2@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <z3jJxWuQYLCx6glwzvc83Z65F_HmEyGrTJOBhv4R8lA=.cc34c0a6-5475-4e25-882a-c1696a8022d2@github.com>
Message-ID: <h0XDk3-j002PCBLr_jnD4guycJTSPH5gaPzsdJFoDto=.1c3b9ee0-1f6e-4cfb-b092-2268fe303dbe@github.com>

On Thu, 3 Jun 2021 02:40:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Yasumasa,
> 
> I'm a bit confused. We seem to have this logic in two places - one in the VM and one in the JDK libraries. Shouldn't this fix look like the fix for JDK-8265836? Can we have just one chunk of code that handles all this?

FWIW, this duplication is pre-existing. One `cpuLoad()` implementation is in the JMX mbean native code:
https://github.com/openjdk/jdk/blob/5ebd4199cc57b60ab7345a019d000c0017a90fc3/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L246
another in os_perf_linux.cpp in HotSpot:
https://github.com/openjdk/jdk/blob/5ebd4199cc57b60ab7345a019d000c0017a90fc3/src/hotspot/os/linux/os_perf_linux.cpp#L338

This patch doesn't change that. But yes, I agree, there are too many areas in HotSpot and JDK library code where duplicated or similar code is present.

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

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

From mgronlun at openjdk.java.net  Mon Jun  7 10:16:59 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 7 Jun 2021 10:16:59 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <oOIS3GK7ADDGUUi1aP6pfYbTNvhuqTBoBV40g5RAAEY=.69892927-09b9-4abf-8a66-391bc2d96be2@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
 <oOIS3GK7ADDGUUi1aP6pfYbTNvhuqTBoBV40g5RAAEY=.69892927-09b9-4abf-8a66-391bc2d96be2@github.com>
Message-ID: <gNC0Gv1eb5E1Vk454oSDOiA2ZqoxwJKGjC9vWXOyIwU=.75aed8ed-6599-42cb-a8a2-f71f8954ae59@github.com>

On Mon, 7 Jun 2021 07:44:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a race-condition and will potentially fail just the same way the bug in #4224 did. There needs to be at least Atomic::loads of the the variables, or the compiler could convert the loads into multiple loads.
>
> @stefank has explained in the bug report why the assertion is not the issue - thanks. So I have to question the validity of just side-stepping the assertion without trying to fix the broken code. What are the implications of finding these broken invariants in the product code? Do we just report/print an incorrect value?

@dholmes-ora The existing mechanism is broken in that it is racy, it reads the pointers being updated by another thread. It attempts to parry for reading problematic values by comparing the used_bytes against the max_tlab_size, to avoid reporting really offside values. A safer means would be to pick up and report only the bytes the owner of the tlab reported already (I..e _allocated_bytes), but this means the value reported will then trail by one tlab, and the impact of doing this is right now is unknown. It could also involve introducing some protocol in how the threads publish their values from their TLABs. All of this can be done of course, but I am not sure this can be addressed straight away. Since testing suffers because the existing behaviour that has been in place for years is now starting to hit the newly introduced assert, this is a workaround, not a fix. It's not clear what the real fix is, so maybe we can create another issue to attempt to figure that out.

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

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

From xliu at openjdk.java.net  Mon Jun  7 10:23:08 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Jun 2021 10:23:08 GMT
Subject: Integrated: 8267926: AsyncLogGtest.java fails on assert with:
 decorator was not part of the decorator set specified at creation.
In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com>
Message-ID: <fG10MlSXZiPEmYj2xALW1mFfwm65NU-2yyQSDdk2BPs=.88ef4cbc-06b5-4602-b771-5b9a5ea5a02a@github.com>

On Fri, 28 May 2021 22:15:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

> The root cause of the intermittent failure is that _decorators in LogDecorations 
> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a
> Log output via set_log_config(TestLogFileName, "all=off").
> 
> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. 
> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms.

This pull request has now been integrated.

Changeset: b09d8b98
Author:    Xin Liu <xliu at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b09d8b9800329f946df80026d61cd4abf41cff37
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation.

Reviewed-by: dholmes, phh

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

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

From david.holmes at oracle.com  Mon Jun  7 10:31:45 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Jun 2021 20:31:45 +1000
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <gNC0Gv1eb5E1Vk454oSDOiA2ZqoxwJKGjC9vWXOyIwU=.75aed8ed-6599-42cb-a8a2-f71f8954ae59@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
 <oOIS3GK7ADDGUUi1aP6pfYbTNvhuqTBoBV40g5RAAEY=.69892927-09b9-4abf-8a66-391bc2d96be2@github.com>
 <gNC0Gv1eb5E1Vk454oSDOiA2ZqoxwJKGjC9vWXOyIwU=.75aed8ed-6599-42cb-a8a2-f71f8954ae59@github.com>
Message-ID: <17b6fe9c-2681-7146-1d97-762ecd859361@oracle.com>

On 7/06/2021 8:16 pm, Markus Gr?nlund wrote:
> On Mon, 7 Jun 2021 07:44:25 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> This is a race-condition and will potentially fail just the same way the bug in #4224 did. There needs to be at least Atomic::loads of the the variables, or the compiler could convert the loads into multiple loads.
>>
>> @stefank has explained in the bug report why the assertion is not the issue - thanks. So I have to question the validity of just side-stepping the assertion without trying to fix the broken code. What are the implications of finding these broken invariants in the product code? Do we just report/print an incorrect value?
> 
> @dholmes-ora The existing mechanism is broken in that it is racy, it reads the pointers being updated by another thread. It attempts to parry for reading problematic values by comparing the used_bytes against the max_tlab_size, to avoid reporting really offside values. A safer means would be to pick up and report only the bytes the owner of the tlab reported already (I..e _allocated_bytes), but this means the value reported will then trail by one tlab, and the impact of doing this is right now is unknown. It could also involve introducing some protocol in how the threads publish their values from their TLABs. All of this can be done of course, but I am not sure this can be addressed straight away. Since testing suffers because the existing behaviour that has been in place for years is now starting to hit the newly introduced assert, this is a workaround, not a fix. It's not clear what the real fix is, so maybe we can create another issue to attempt to figure that out.

Okay, please file an issue for the real issue.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4363
> 

From david.holmes at oracle.com  Mon Jun  7 10:33:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Jun 2021 20:33:43 +1000
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <h0XDk3-j002PCBLr_jnD4guycJTSPH5gaPzsdJFoDto=.1c3b9ee0-1f6e-4cfb-b092-2268fe303dbe@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <z3jJxWuQYLCx6glwzvc83Z65F_HmEyGrTJOBhv4R8lA=.cc34c0a6-5475-4e25-882a-c1696a8022d2@github.com>
 <h0XDk3-j002PCBLr_jnD4guycJTSPH5gaPzsdJFoDto=.1c3b9ee0-1f6e-4cfb-b092-2268fe303dbe@github.com>
Message-ID: <3c80fa01-8254-950c-64b7-8dc1b0f8c4b8@oracle.com>

On 7/06/2021 8:00 pm, Severin Gehwolf wrote:
> On Thu, 3 Jun 2021 02:40:16 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Hi Yasumasa,
>>
>> I'm a bit confused. We seem to have this logic in two places - one in the VM and one in the JDK libraries. Shouldn't this fix look like the fix for JDK-8265836? Can we have just one chunk of code that handles all this?
> 
> FWIW, this duplication is pre-existing. One `cpuLoad()` implementation is in the JMX mbean native code:
> https://github.com/openjdk/jdk/blob/5ebd4199cc57b60ab7345a019d000c0017a90fc3/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L246
> another in os_perf_linux.cpp in HotSpot:
> https://github.com/openjdk/jdk/blob/5ebd4199cc57b60ab7345a019d000c0017a90fc3/src/hotspot/os/linux/os_perf_linux.cpp#L338
> 
> This patch doesn't change that. But yes, I agree, there are too many areas in HotSpot and JDK library code where duplicated or similar code is present.

Leaving aside that consolidating to one copy of the code should be done 
as a future RFE, shouldn't the existing two copies behave in exactly the 
same way?

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4299
> 

From github.com+42899633+eastig at openjdk.java.net  Mon Jun  7 11:26:12 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Mon, 7 Jun 2021 11:26:12 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData()
In-Reply-To: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
Message-ID: <YMVNLoGtE3vHgbYstUjeQACqfcAZOGcmdPYsl3qNtks=.6091cd04-bb9b-4304-9c52-fa07345d3abe@github.com>

On Mon, 7 Jun 2021 03:31:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.

src/hotspot/share/classfile/classLoaderData.cpp line 699:

> 697:   // Method::clear_jmethod_ids only sets the jmethod_ids to NULL without
> 698:   // releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
> 699:   // This is done intentionally because native code (e.g. JVMTI agent) obtains

Maybe rewriting to "native code (...) holding jmethod_ids may access..." would be clearer?

src/hotspot/share/classfile/classLoaderData.cpp line 701:

> 699:   // This is done intentionally because native code (e.g. JVMTI agent) obtains
> 700:   // jmethod_ids may access them after the associated classes and class loader
> 701:   // are unloaded. The Java native Interface Specification says "method ID

"native" -> "Native"

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

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

From zgu at openjdk.java.net  Mon Jun  7 12:21:01 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 7 Jun 2021 12:21:01 GMT
Subject: RFR: JDK-8268018: remove dead code in commitLimitter
In-Reply-To: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
References: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
Message-ID: <CR9-4Hjtz47gW0J3mMv9_QxQTqjT8mgjAjaMcACMKmw=.b811b611-98d1-4761-8d5b-ade288638265@github.com>

On Thu, 3 Jun 2021 01:56:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

> it's trivial cleanup to remove some dead code.

Looks good and trivial

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

Marked as reviewed by zgu (Reviewer).

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

From sgehwolf at openjdk.java.net  Mon Jun  7 12:28:59 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 7 Jun 2021 12:28:59 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
Message-ID: <cCI_whJLUzHKxy0Wk9Jc2ch0sVdqpUCmDvbjsblY_B0=.36bbba42-a1ae-4efc-89b0-adc89149dca2@github.com>

On Wed, 2 Jun 2021 06:59:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jdk.CPULoad event reports CPU usage.
> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
> 
> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
> 
> 
> public class InfiniteLoop{
>   public static void main(String[] args){
>     while(true){
>     }
>   }
> }
> 
> 
> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
[...]

> Leaving aside that consolidating to one copy of the code should be done
> as a future RFE, shouldn't the existing two copies behave in exactly the
> same way?

Yes, I agree. My comment wasn't really a review of any kind, just mentioning the status quo.

Since there has been [JDK-8203359](https://bugs.openjdk.java.net/browse/JDK-8203359) implemented in JDK 17 I wonder if changing jdk.CPULoad event the way it's proposed makes sense. Maybe `ContainerCPUUsage` event should be used in order to gather this info instead?

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

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

From ysuenaga at openjdk.java.net  Mon Jun  7 12:44:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 7 Jun 2021 12:44:05 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <cCI_whJLUzHKxy0Wk9Jc2ch0sVdqpUCmDvbjsblY_B0=.36bbba42-a1ae-4efc-89b0-adc89149dca2@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <cCI_whJLUzHKxy0Wk9Jc2ch0sVdqpUCmDvbjsblY_B0=.36bbba42-a1ae-4efc-89b0-adc89149dca2@github.com>
Message-ID: <dOYIEA1WmJL3wfga7sXGL0zh9HT8qtMu47n_uV91K9Q=.1bc2cb01-954a-4249-b8f1-9dd983835eec@github.com>

On Mon, 7 Jun 2021 12:26:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Since there has been [JDK-8203359](https://bugs.openjdk.java.net/browse/JDK-8203359) implemented in JDK 17 I wonder if changing jdk.CPULoad event the way it's proposed makes sense. Maybe `ContainerCPUUsage` event should be used in order to gather this info instead?

I guess `ContainerCPUUsage` is more suitable rather than `CPULoad` in this case, but it is not documented. I aware this problem when I load flight record on JMC 8 - it seems to use `CPULoad` event to draw CPU usage chart. So JFR user might mislead CPU usage for their apps.

And also this problem affects CPU time in thread dump as I said before. It is not JFR event.

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

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

From ysuenaga at openjdk.java.net  Mon Jun  7 12:47:58 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 7 Jun 2021 12:47:58 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
Message-ID: <tXPPQg4otXyICw7tqb314-6MRGNRr8as_mAd_nFRZaE=.0739cd5f-2054-4484-acf8-7542918b31de@github.com>

On Wed, 2 Jun 2021 06:59:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jdk.CPULoad event reports CPU usage.
> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
> 
> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
> 
> 
> public class InfiniteLoop{
>   public static void main(String[] args){
>     while(true){
>     }
>   }
> }
> 
> 
> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.

CPULoad in JMX returns container CPU usage if JVM runs on the container.
If JFR distinguishes ContainerCPUUsage and  CPULoad, it is odd a bit. It seems to be inconsistent.

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

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

From mli at openjdk.java.net  Mon Jun  7 13:39:40 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 7 Jun 2021 13:39:40 GMT
Subject: RFR: JDK-8268018: remove dead code in commitLimitter
In-Reply-To: <CR9-4Hjtz47gW0J3mMv9_QxQTqjT8mgjAjaMcACMKmw=.b811b611-98d1-4761-8d5b-ade288638265@github.com>
References: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
 <CR9-4Hjtz47gW0J3mMv9_QxQTqjT8mgjAjaMcACMKmw=.b811b611-98d1-4761-8d5b-ade288638265@github.com>
Message-ID: <StPgRP10fmfBJpY6yQRJS3w-FARTPujH1zKn4MQvkY4=.f000f26a-5a0d-48d2-b0a7-2899a0caa1af@github.com>

On Mon, 7 Jun 2021 12:17:39 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> it's trivial cleanup to remove some dead code.
>
> Looks good and trivial

@zhengyu123 @navyxliu Thanks for your review.

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

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

From mli at openjdk.java.net  Mon Jun  7 13:45:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 7 Jun 2021 13:45:41 GMT
Subject: Integrated: JDK-8268018: remove dead code in commitLimitter
In-Reply-To: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
References: <i7AJgc_jYV-mA7yKaommuEc5K1X9NYwD-dDFX_cP3IE=.5accba8d-92c6-4221-ab4a-c90105ae048c@github.com>
Message-ID: <rWoOCPSTSSzydcwhPh7NJoDWl1v3ulfaCHZpEQu_ljo=.6a499adb-e183-4c35-af65-00e2b6b445a8@github.com>

On Thu, 3 Jun 2021 01:56:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

> it's trivial cleanup to remove some dead code.

This pull request has now been integrated.

Changeset: 728a411a
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/728a411a541f93121bbd7db4258859196bcf6cdf
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8268018: remove dead code in commitLimitter

Reviewed-by: zgu

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

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

From sgehwolf at openjdk.java.net  Mon Jun  7 13:58:28 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 7 Jun 2021 13:58:28 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
Message-ID: <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>

On Wed, 2 Jun 2021 06:59:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jdk.CPULoad event reports CPU usage.
> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
> 
> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
> 
> 
> public class InfiniteLoop{
>   public static void main(String[] args){
>     while(true){
>     }
>   }
> }
> 
> 
> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.

I'm concerned this implementation isn't correct.

> CPULoad in JMX returns container CPU usage if JVM runs on the container.
> If JFR distinguishes ContainerCPUUsage and CPULoad, it is odd a bit. It seems to be inconsistent.

My understanding was that for JFR it's interesting to "see" both kinds of events. Host CPU load and what's reported for the container. Then do some analysis across them.

> And also this problem affects CPU time in thread dump as I said before. It is not JFR event.

OK, good point.

src/hotspot/os/linux/os_perf_linux.cpp line 404:

> 402:     }
> 403:     *pkernelLoad *= scale;
> 404:     user_load *= scale;

If I read this correctly the cpu load would only be scaled to the number of configured container limits with no bearing of the actual cpu usage of processes within the container. For example: Let process A be running in container A' with X/2 cpus and process B running in container B' with X/2 cpus. X are the total number of cpus available on a host. Then A is using 100% cpu (i.e. `1.0`) and B is being idle (i.e. close to `0.0`). With this patch I'd get a CPU load report of about `1.0` for each container, A' and B'. Am I missing something?

On the JDK side we have `Metrics.getCpuUsage()` API which isn't present in HotSpot code. I believe we'd have to have a similar API in OSContainer in order to implement this correctly. Thoughts?

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

Changes requested by sgehwolf (Reviewer).

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

From mgronlun at openjdk.java.net  Mon Jun  7 14:15:56 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 7 Jun 2021 14:15:56 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
Message-ID: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>

> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
> 
> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
> 
> Testing: tier1, tier2, tier6, tier8
> 
> Thanks
> Markus

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

  read once

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4363/files
  - new: https://git.openjdk.java.net/jdk/pull/4363/files/8e2bc9a0..46eeb2d8

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

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

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

From dcubed at openjdk.java.net  Mon Jun  7 15:20:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 7 Jun 2021 15:20:20 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>

On Tue, 1 Jun 2021 20:52:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

Ping! Any takers?
@dholmes-ora and @plummercj - You both reviewed the related test work done in:
     JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
Any chance you have the cycles for these updates this week?

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

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

From ysuenaga at openjdk.java.net  Mon Jun  7 15:40:17 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 7 Jun 2021 15:40:17 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>
Message-ID: <4YK4ENpY9i4oxXvX-7Q-4rRpvcQ_3_tMbEaqJxib92w=.b3c6959a-0415-400b-b2d3-2c093dfd59b7@github.com>

On Mon, 7 Jun 2021 13:44:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> jdk.CPULoad event reports CPU usage.
>> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
>> 
>> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
>> 
>> 
>> public class InfiniteLoop{
>>   public static void main(String[] args){
>>     while(true){
>>     }
>>   }
>> }
>> 
>> 
>> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.
>
> src/hotspot/os/linux/os_perf_linux.cpp line 404:
> 
>> 402:     }
>> 403:     *pkernelLoad *= scale;
>> 404:     user_load *= scale;
> 
> If I read this correctly the cpu load would only be scaled to the number of configured container limits with no bearing of the actual cpu usage of processes within the container. For example: Let process A be running in container A' with X/2 cpus and process B running in container B' with X/2 cpus. X are the total number of cpus available on a host. Then A is using 100% cpu (i.e. `1.0`) and B is being idle (i.e. close to `0.0`). With this patch I'd get a CPU load report of about `1.0` for each container, A' and B'. Am I missing something?
> 
> On the JDK side we have `Metrics.getCpuUsage()` API which isn't present in HotSpot code. I believe we'd have to have a similar API in OSContainer in order to implement this correctly. Thoughts?

My proposal shows correctly both `jvmUser` and `jvmSystem` in your case, however `machineTotal` is incorrect (100%). I need to tweak it.

> On the JDK side we have `Metrics.getCpuUsage()` API which isn't present in HotSpot code. I believe we'd have to have a similar API in OSContainer in order to implement this correctly. Thoughts?

It is better to do so, but I thought it is much simpler if we can handle CPU quotas correctly.
I understand it is better if it is same logic between JDK and HotSpot, but I thought we can work for it in future RFE. Isn't it?

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

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

From jiangli at openjdk.java.net  Mon Jun  7 15:50:50 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Mon, 7 Jun 2021 15:50:50 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
Message-ID: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>

> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Remove whitespace.
 - Updated based on Evgeny's comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4383/files
  - new: https://git.openjdk.java.net/jdk/pull/4383/files/2ae0b3f0..17ddc32f

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

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

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

From jiangli at openjdk.java.net  Mon Jun  7 15:50:55 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Mon, 7 Jun 2021 15:50:55 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <YMVNLoGtE3vHgbYstUjeQACqfcAZOGcmdPYsl3qNtks=.6091cd04-bb9b-4304-9c52-fa07345d3abe@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <YMVNLoGtE3vHgbYstUjeQACqfcAZOGcmdPYsl3qNtks=.6091cd04-bb9b-4304-9c52-fa07345d3abe@github.com>
Message-ID: <7PT64eozu3yqTziYDxHfcph2U_whe7HhSGCnSEhZFYI=.ebd4073b-ff83-47d0-a0a3-475fae0d125d@github.com>

On Mon, 7 Jun 2021 11:22:59 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove whitespace.
>>  - Updated based on Evgeny's comments.
>
> src/hotspot/share/classfile/classLoaderData.cpp line 699:
> 
>> 697:   // Method::clear_jmethod_ids only sets the jmethod_ids to NULL without
>> 698:   // releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>> 699:   // This is done intentionally because native code (e.g. JVMTI agent) obtains
> 
> Maybe rewriting to "native code (...) holding jmethod_ids may access..." would be clearer?

Updated as suggested. Thanks!

> src/hotspot/share/classfile/classLoaderData.cpp line 701:
> 
>> 699:   // This is done intentionally because native code (e.g. JVMTI agent) obtains
>> 700:   // jmethod_ids may access them after the associated classes and class loader
>> 701:   // are unloaded. The Java native Interface Specification says "method ID
> 
> "native" -> "Native"

Done.

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

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

From github.com+42899633+eastig at openjdk.java.net  Mon Jun  7 17:58:20 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Mon, 7 Jun 2021 17:58:20 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
Message-ID: <KsEAvVSzOVAUn1TPdYUfdLYsN7Qb1tE5Lvp6COR6noA=.7e3c8bfa-e8c3-4c00-a368-fb53f1c29a48@github.com>

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

LGTM

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

Marked as reviewed by eastig at github.com (no known OpenJDK username).

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

From cjplummer at openjdk.java.net  Mon Jun  7 17:58:16 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 17:58:16 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>
Message-ID: <u1JZ14zEDXVHpXiI1pvJ-1dlqvbG8dyabGZEnYYIxGE=.1a815a1d-8790-4433-8b85-4f6debc1b89c@github.com>

On Mon, 7 Jun 2021 15:17:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>  @dholmes-ora and @plummercj - You both reviewed the related test work done in:
> JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
> Any chance you have the cycles for these updates this week?

Yes. Hopefully in the next day or two.

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

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

From jiangli at openjdk.java.net  Mon Jun  7 18:11:18 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Mon, 7 Jun 2021 18:11:18 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
Message-ID: <LaHto3AybJqOwmQYmyEDRtAMSVtD09jCdoKQoOX0U9g=.9bbd5bdf-7d8d-4446-94ad-f43cf98e6231@github.com>

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

Thanks for the review!

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

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

From coleenp at openjdk.java.net  Mon Jun  7 18:45:21 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Jun 2021 18:45:21 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
Message-ID: <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>

On Mon, 7 Jun 2021 18:40:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove whitespace.
>>  - Updated based on Evgeny's comments.
>
> src/hotspot/share/classfile/classLoaderData.cpp line 705:
> 
>> 703:   // been derived. After the class is unloaded, the method or field ID becomes
>> 704:   // invalid". In real world usages, the native code may rely on jmethod_ids
>> 705:   // being NULL after class unloading. Hence, it is unsafe to free the memory
> 
> Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
> All or most of the JNI functions will crash with a NULL'ed out jmethodID.  You can catch this error by using -Xcheck:jni.  Maybe we could deprecate this feature of the JVMTI spec and release the memory?

This comment looks like an expanded version of the one I wrote a long time ago and correct.  We were wondering if this is a feature that we actually need.

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

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

From coleenp at openjdk.java.net  Mon Jun  7 18:45:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Jun 2021 18:45:20 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
Message-ID: <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

src/hotspot/share/classfile/classLoaderData.cpp line 705:

> 703:   // been derived. After the class is unloaded, the method or field ID becomes
> 704:   // invalid". In real world usages, the native code may rely on jmethod_ids
> 705:   // being NULL after class unloading. Hence, it is unsafe to free the memory

Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
All or most of the JNI functions will crash with a NULL'ed out jmethodID.  You can catch this error by using -Xcheck:jni.  Maybe we could deprecate this feature of the JVMTI spec and release the memory?

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

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

From darcy at openjdk.java.net  Mon Jun  7 19:38:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Jun 2021 19:38:58 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v5]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <4iK7aNo0h9tnnDn_doTG5Fv3BPYyQkRGIzbiiM3D9BU=.f4efa3b8-6ac6-4906-8de9-7fb2c5e9feef@github.com>

> 8267630: Start of release updates for JDK 18

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 17 additional commits since the last revision:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Update symbols for JDK 17 b25.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/947ea6f5...34480e50

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4175/files
  - new: https://git.openjdk.java.net/jdk/pull/4175/files/f926c1bc..34480e50

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

  Stats: 24229 lines in 300 files changed: 22483 ins; 936 del; 810 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

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

From jiangli at openjdk.java.net  Mon Jun  7 19:56:17 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Mon, 7 Jun 2021 19:56:17 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
Message-ID: <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>

On Mon, 7 Jun 2021 18:43:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderData.cpp line 705:
>> 
>>> 703:   // been derived. After the class is unloaded, the method or field ID becomes
>>> 704:   // invalid". In real world usages, the native code may rely on jmethod_ids
>>> 705:   // being NULL after class unloading. Hence, it is unsafe to free the memory
>> 
>> Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
>> All or most of the JNI functions will crash with a NULL'ed out jmethodID.  You can catch this error by using -Xcheck:jni.  Maybe we could deprecate this feature of the JVMTI spec and release the memory?
>
> This comment looks like an expanded version of the one I wrote a long time ago and correct.  We were wondering if this is a feature that we actually need.

> Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
> All or most of the JNI functions will crash with a NULL'ed out jmethodID. You can catch this error by using -Xcheck:jni. Maybe we could deprecate this feature of the JVMTI spec and release the memory?

The JVMTI agent use case that ran into issues (with releasing memory) calls GetMethodDeclaringClass for a stale jmethod_id (with unloaded class and loader) and crashes in Method::checked_resolve_jmethod_id when it's dereferencing the 'mid'.

The agent native code does check for JVMTI_ERROR_NONE after calling GetMethodDeclaringClass in this case, but it's too late.

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

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

From jiangli at openjdk.java.net  Mon Jun  7 20:03:21 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Mon, 7 Jun 2021 20:03:21 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
Message-ID: <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>

On Mon, 7 Jun 2021 19:53:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This comment looks like an expanded version of the one I wrote a long time ago and correct.  We were wondering if this is a feature that we actually need.
>
>> Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
>> All or most of the JNI functions will crash with a NULL'ed out jmethodID. You can catch this error by using -Xcheck:jni. Maybe we could deprecate this feature of the JVMTI spec and release the memory?
> 
> The JVMTI agent use case that ran into issues (with releasing memory) calls GetMethodDeclaringClass for a stale jmethod_id (with unloaded class and loader) and crashes in Method::checked_resolve_jmethod_id when it's dereferencing the 'mid'.
> 
> The agent native code does check for JVMTI_ERROR_NONE after calling GetMethodDeclaringClass in this case, but it's too late.

> This comment looks like an expanded version of the one I wrote a long time ago and correct. 

Thanks for confirming the correctness!

> We were wondering if this is a feature that we actually need.

That seems to be the case. I learned this the hard way with crashes observed in production when attempting to release memory for stale jmethod_ids from VM side. Clarifying the comments hopefully will benefit others and avoid similar issues in the future.

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

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

From dcubed at openjdk.java.net  Mon Jun  7 20:12:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 7 Jun 2021 20:12:30 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v6]
In-Reply-To: <8yz8b4bqC7aZuAcBC7sFWdL7mTkFc4zDwyAn3Cg-yEU=.089f3a7a-23c8-4e68-aa5c-ffc71d9ee7bd@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <8yz8b4bqC7aZuAcBC7sFWdL7mTkFc4zDwyAn3Cg-yEU=.089f3a7a-23c8-4e68-aa5c-ffc71d9ee7bd@github.com>
Message-ID: <ddj2wV4mjXnMaMdJtDkDhyo30gHdfcmt2a_ClOETDEc=.fda93873-f0c6-45f8-8bcb-af6a17e136cf@github.com>

On Mon, 7 Jun 2021 09:07:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into handshakee
>  - Merge branch 'master' into handshakee
>  - Added comment
>  - Small review updates
>  - Merge branch 'master' into handshakee
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - Fix

I did a crawl thru review of the v05 full webrev.
Thumbs up.

There are a few copyright years that need to be updated.

src/hotspot/share/utilities/filterQueue.hpp line 68:

> 66:   // exclusive to other contains and pops calls.
> 67:   template <typename MATCH_FUNC>
> 68:   bool contains(MATCH_FUNC& match_func);

Need to update the copyright for this file.

src/hotspot/share/utilities/filterQueue.inline.hpp line 114:

> 112:   } while (true);
> 113: }
> 114: 

Need to update the copyright for this file.

test/hotspot/gtest/utilities/test_filterQueue.cpp line 58:

> 56: static void is_empty(FilterQueue<uintptr_t>& queue) {
> 57:   EXPECT_EQ(queue.is_empty(), true) << "Must be empty.";
> 58:   EXPECT_EQ(queue.contains(match_1), false) << "Must be empty.";

Need to update the copyright for this file.

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.java.net  Mon Jun  7 20:22:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 7 Jun 2021 20:22:17 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
Message-ID: <DyYlfVt6ORpPQ4OIjBPiwvcXBc2NMThgp8KqBkFqr6Y=.729ae9aa-3263-42e2-9f4e-9227f6f76f0d@github.com>

On Mon, 7 Jun 2021 14:15:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   read once

Thumbs up.

Should the `_start` and `_top` fields be marked `volatile` to
prevent the S390 compiler from "optimizing" like it did with
another recent bug (JDK-8267842)?

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

Marked as reviewed by dcubed (Reviewer).

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

From iris at openjdk.java.net  Mon Jun  7 20:42:19 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 7 Jun 2021 20:42:19 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v5]
In-Reply-To: <4iK7aNo0h9tnnDn_doTG5Fv3BPYyQkRGIzbiiM3D9BU=.f4efa3b8-6ac6-4906-8de9-7fb2c5e9feef@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
 <4iK7aNo0h9tnnDn_doTG5Fv3BPYyQkRGIzbiiM3D9BU=.f4efa3b8-6ac6-4906-8de9-7fb2c5e9feef@github.com>
Message-ID: <vP72LkKCXSrbbnmiZgVjNT6wGTmQQs6gVpzBJG3W9_4=.a3486793-d4e4-4eb4-862c-6afcba40ca60@github.com>

On Mon, 7 Jun 2021 19:38:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8267630: Start of release updates for JDK 18
>
> 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Update symbols for JDK 17 b25.
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/41bce524...34480e50

Marked as reviewed by iris (Reviewer).

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 22:13:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 22:13:18 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>

On Tue, 1 Jun 2021 20:52:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java line 82:

> 80:                 thread.exitSyncObj.countDown();
> 81:                 while (true) {
> 82:                     thread.interrupt();

I just want to make sure I correctly understand the intent here. You call countDown() to unblock the thread's run() method, and then immediately interrupt the thread to create a race between the thread doing a normal exit and the thread being interrupted before or as it exits.

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 22:22:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 22:22:17 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <vPMvlvTwEOFYzBXW8uY7uw5imZ2wPAWFPfPaYkLTN-w=.647dddf8-24d8-4420-9bf5-237edb4e6bfb@github.com>

On Tue, 1 Jun 2021 20:52:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 88:

> 86:                 thread.exitSyncObj.countDown();
> 87:                 while (true) {
> 88:                     thread.stop();

It seems the main() method of these 6 or so thread tests are identical except for the one Thread API you call at this location. Have you considered refactoring so there is only one copy of all the common code?

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 22:42:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 22:42:18 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <6g5yT7skh82ZBGp434BBgtvs6dtVt54KAQUKHIlvdZg=.695aae78-2c75-480c-8d16-6ecd75af9065@github.com>

On Tue, 1 Jun 2021 20:52:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java line 105:

> 103:         }
> 104: 
> 105:         System.out.println("Case 2: java.lang.Thread.interrupt()");

Was Case 2 removed because it is covered by runtime/Thread/InterruptAtExit.java

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 23:14:19 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 23:14:19 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <2bB3v2yhqpN450yxDBUw-EufYa5LYk2S0-5POqHOWCE=.5a55bb9b-89d9-45d6-9683-afaa9c472f4c@github.com>

On Tue, 1 Jun 2021 20:52:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:

> 100:         /*
> 101:          * Using printf() instead of NSK_DISPLAY1() in this loop
> 102:          * in order to slow down the rate of SuspendThread() calls.

I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.

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

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

From iklam at openjdk.java.net  Mon Jun  7 23:40:34 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 7 Jun 2021 23:40:34 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes [v2]
In-Reply-To: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
Message-ID: <TePCZb1YWu7ppQlN8lQdI0HuWqGlSCwG_PdL5sbBEEg=.be384336-8a66-4cb1-baf8-5d97e1be3d28@github.com>

> This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 
> 
> Requested by @rose00 (sorry I took a long time ....).

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

  @coleenp comments; clean up

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4327/files
  - new: https://git.openjdk.java.net/jdk/pull/4327/files/b0db2f36..f5b83fb0

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

  Stats: 10 lines in 1 file changed: 1 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4327.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4327/head:pull/4327

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

From iklam at openjdk.java.net  Mon Jun  7 23:40:34 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 7 Jun 2021 23:40:34 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes
In-Reply-To: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
Message-ID: <boBigICrmHGHRrS4UZ3WsrkWsJADpmDDYR4CE4zACGY=.90e6484a-da34-4db6-ba31-c73da1e83c3f@github.com>

On Thu, 3 Jun 2021 00:36:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 
> 
> Requested by @rose00 (sorry I took a long time ....).

I cleaned up the comments per Coleen's comments. I also removed the "debug only" comment about on_stack() since in most cases they are inline functions and will be elided by the compiler anyway.

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

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

From dcubed at openjdk.java.net  Mon Jun  7 23:53:16 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 7 Jun 2021 23:53:16 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>
Message-ID: <KUaHMvSSDqarKQtc0buxns-LjQlWiC9XZhbXwh0ebKo=.2fd9fa98-8ca2-4f12-a5f1-0dc7902ecfbd@github.com>

On Mon, 7 Jun 2021 22:09:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply @plummercj code review fix from JDK-8265153 to this review also.
>
> test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java line 82:
> 
>> 80:                 thread.exitSyncObj.countDown();
>> 81:                 while (true) {
>> 82:                     thread.interrupt();
> 
> I just want to make sure I correctly understand the intent here. You call countDown() to unblock the thread's run() method, and then immediately interrupt the thread to create a race between the thread doing a normal exit and the thread being interrupted before or as it exits.

That is correct. The intention is to stress the Thread.interrupt() calls
on the exiting thread.

> test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 88:
> 
>> 86:                 thread.exitSyncObj.countDown();
>> 87:                 while (true) {
>> 88:                     thread.stop();
> 
> It seems the main() method of these 6 or so thread tests are identical except for the one Thread API you call at this location. Have you considered refactoring so there is only one copy of all the common code?

Not really. It would be harder to use one of these tests in a standalone
fashion outside of JTREG runs if it depended on another .java file.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java line 105:
> 
>> 103:         }
>> 104: 
>> 105:         System.out.println("Case 2: java.lang.Thread.interrupt()");
> 
> Was Case 2 removed because it is covered by runtime/Thread/InterruptAtExit.java

Yes, it seemed like duplicated coverage to me.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:
> 
>> 100:         /*
>> 101:          * Using printf() instead of NSK_DISPLAY1() in this loop
>> 102:          * in order to slow down the rate of SuspendThread() calls.
> 
> I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.

I couldn't remember why I did that when I wrote the test so
I removed it.

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

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

From minqi at openjdk.java.net  Tue Jun  8 00:06:24 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 8 Jun 2021 00:06:24 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes [v2]
In-Reply-To: <TePCZb1YWu7ppQlN8lQdI0HuWqGlSCwG_PdL5sbBEEg=.be384336-8a66-4cb1-baf8-5d97e1be3d28@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
 <TePCZb1YWu7ppQlN8lQdI0HuWqGlSCwG_PdL5sbBEEg=.be384336-8a66-4cb1-baf8-5d97e1be3d28@github.com>
Message-ID: <ZyUWNGEyIiU9zK1tISjdJGl9gjY67roM1hlfMlNAO18=.f125e9ac-98f3-48ed-b575-ddfc0a4e8835@github.com>

On Mon, 7 Jun 2021 23:40:34 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 
>> 
>> Requested by @rose00 (sorry I took a long time ....).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments; clean up

Looks good.

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

Marked as reviewed by minqi (Reviewer).

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

From ccheung at openjdk.java.net  Tue Jun  8 00:37:39 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 8 Jun 2021 00:37:39 GMT
Subject: RFR: 8267556: Enhance class paths check during runtime
Message-ID: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>

During CDS dump time, if an entry in the classpath isn't a jar file, the entry will not be recorded in the archive header. However, during runtime, it attempts to compare all the entries in the classpath against the entries from the archive header. The loading of CDS archive would fail if there exists an non-jar entry in the classpath.

The proposed patch addresses the above issue. It adds a `bool _has_non_jar_in_classpath` to indicate if a non-jar entry has been encountered during dump time in the archive header. This is to minimize the performance impact for the usual cases where there is no non-jar entry in the classpath.

- [x] mach5 tiers 1 - 4 (including the new test)

This is targeted for JDK18.

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

Commit messages:
 - 8267556: Enhance class paths check during runtime

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

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

From iklam at openjdk.java.net  Tue Jun  8 00:56:13 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Jun 2021 00:56:13 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
Message-ID: <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>

On Mon, 7 Jun 2021 20:00:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
>>> All or most of the JNI functions will crash with a NULL'ed out jmethodID. You can catch this error by using -Xcheck:jni. Maybe we could deprecate this feature of the JVMTI spec and release the memory?
>> 
>> The JVMTI agent use case that ran into issues (with releasing memory) calls GetMethodDeclaringClass for a stale jmethod_id (with unloaded class and loader) and crashes in Method::checked_resolve_jmethod_id when it's dereferencing the 'mid'.
>> 
>> The agent native code does check for JVMTI_ERROR_NONE after calling GetMethodDeclaringClass in this case, but it's too late.
>
>> This comment looks like an expanded version of the one I wrote a long time ago and correct. 
> 
> Thanks for confirming the correctness!
> 
>> We were wondering if this is a feature that we actually need.
> 
> That seems to be the case. I learned this the hard way with crashes observed in production when attempting to release memory for stale jmethod_ids from VM side. Clarifying the comments hopefully will benefit others and avoid similar issues in the future.

If the issue is specific to JVMTI code only, the comment should reflect that. Currently it seems to suggest that all possible JNI code could use an invalid jmethodID. However, using an invalid jmethodID with JNI APIs such as CallStaticVoidMethod will lead to a crash. I don't think the JNI spec allows invalid jmethodID to be used.

Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.

We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?

Lastly, do we have any existing test cases that cover the use of invalid jmethodIDs?

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

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

From jiangli at openjdk.java.net  Tue Jun  8 01:17:16 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 01:17:16 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
Message-ID: <TialA6pgwu2BHCGC1CkDvNhpyOZUCNjelx7WQ2zMHaU=.66e05c02-9e35-46bb-8b7d-abe354c8c402@github.com>

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

Hi Coleen,

Some more background context related to this:

Users/developers would be happy if we can release memory for jmethod_ids in unloaded cases and get rid of the memory leak. I was pinged recently for the leak after the earlier unsuccessful attempt to fix with https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9 change (on JDK 11, and was rollback due to agent crashes). I haven't found a general solution that would work well without the memory leak.  So decided to clarify the comment for now and also open up the discussion in JDK-8268088.

The agent that ran into crashes with the attempted fix saved stacktraces and jmethod_ids from periodic sampling.  It then tried to get the class and method information (name, etc) from the saved jmethod_ids at later points during the execution and crashed in Method::checked_resolve_jmethod_id with a stale jmethod_id. One possible solution that I thought of was to 'remove' the jmethod_ids in agent during unloading (described in https://bugs.openjdk.java.net/browse/JDK-8268088?focusedCommentId=14424635&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14424635). That could allow deallocating the memory related to those jmethod_ids within the VM. However, that's not a general and efficient solution because:

- It would require a new call back being registered and implemented from the agent. An agent may not choose to do so.  JVM cannot reliably free the memory without a potential SEGV risk with the approach.
- It adds overhead to class unloading. The agent would need to iterate all stored stack traces and find the jmethod_ids related to the classes that are currently being unloaded. That can be expansive and would add noticeable overhead. 
- Also, agent may have bugs and fail to remove a jmethod_ids during the callback.

It would be good if we can find a workable solution for this (for long term).

Thanks!

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

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

From jiangli at openjdk.java.net  Tue Jun  8 02:00:16 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 02:00:16 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
Message-ID: <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>

On Tue, 8 Jun 2021 00:53:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> This comment looks like an expanded version of the one I wrote a long time ago and correct. 
>> 
>> Thanks for confirming the correctness!
>> 
>>> We were wondering if this is a feature that we actually need.
>> 
>> That seems to be the case. I learned this the hard way with crashes observed in production when attempting to release memory for stale jmethod_ids from VM side. Clarifying the comments hopefully will benefit others and avoid similar issues in the future.
>
> If the issue is specific to JVMTI code only, the comment should reflect that. Currently it seems to suggest that all possible JNI code could use an invalid jmethodID. However, using an invalid jmethodID with JNI APIs such as CallStaticVoidMethod will lead to a crash. I don't think the JNI spec allows invalid jmethodID to be used.
> 
> Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.
> 
> We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?
> 
> Lastly, do we have any existing test cases that cover the use of invalid jmethodIDs?

Hi Ioi, thanks for the thoughts!

> If the issue is specific to JVMTI code only, the comment should reflect that. Currently it seems to suggest that all possible JNI code could use an invalid jmethodID. However, using an invalid jmethodID with JNI APIs such as CallStaticVoidMethod will lead to a crash.

The issue that we encountered recently was with a JVMTI profiling agent. However, we can't conclude from that it is only restricted to JVMTI usages. Since we don't have any evidences to exclude non-JVMTI cases, narrowing down the scope of Coleen's existing comment is not a good idea. Expending the comment with clarifications and example (JVMTI agent) is appropriate at this point.

> I don't think the JNI spec allows invalid jmethodID to be used.

I haven't found the specific language in the JNI spec. The quoted spec language in updated comment does not strongly indicate that.

> 
> Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.
> 

It's not just JVMTI vs non-JVMTI issues. The JNIMethodBlocks are not always created. When application native code creates (directly or indirectly) jmethod_ids, how does VM know when it's safe to release the memory? It faces the same issue as the JVMTI agent case. https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9 addresses from unloading point view. However, that's unsafe either.

> We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?
> 

If we update the JNI spec to ban such usages and fix all existing third party code (if we can), we can change the VM to release memory safely. That would be welcomed by developers. However, any unfixed native code would still run into risks of crashes.

> Lastly, do we have any existing test cases that cover the use of invalid jmethodIDs?

Unfortunately there's no existing test case. It would help prevent the crash in production if we had a test case that caught the issue early. It's a good to-do item in addition to the comment clarification, before looking into a potential longer term solution for the memory leak.

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

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

From dholmes at openjdk.java.net  Tue Jun  8 02:15:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 02:15:30 GMT
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack frame
Message-ID: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>

Please review this trivial fix to ensure we do not try to alloca zero bytes.

Thanks,
David

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

Commit messages:
 - 8267908: linux: thread_native_entry can scribble on stack frame

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

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

From dholmes at openjdk.java.net  Tue Jun  8 02:19:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 02:19:15 GMT
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
Message-ID: <Jop2qeysv0eCH2wMtmONgPVdiBJJ9C-EL1er2OPgnGA=.fb11ebe6-57ca-40a6-afe2-59ec601f8563@github.com>

On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to ensure we do not try to alloca zero bytes.
> 
> Thanks,
> David

To test this I flipped the ifndef GLIBC to ifdef GLIBC.

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

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

From ysuenaga at openjdk.java.net  Tue Jun  8 03:11:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 8 Jun 2021 03:11:15 GMT
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
Message-ID: <1ZtcqbSy_wtTLrc7-YruYbqZg3K6SOiZUhjIa5Ca7j8=.8d2be8fa-01ca-4438-b651-77a8a03e6560@github.com>

On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to ensure we do not try to alloca zero bytes.
> 
> Thanks,
> David

Looks good!

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

Marked as reviewed by ysuenaga (Reviewer).

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

From xliu at openjdk.java.net  Tue Jun  8 03:16:23 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Jun 2021 03:16:23 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags and
 decorators
Message-ID: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>

Support dynamic reconfiguration for async logging. 2 unittests are provided.
The regression test discovers a race condition in LogTagSet::log() even with
synchronous logging. It's not MT-safe if context switch happens between the
creation of LogDecorations  and LogOutputList::Iterator. fixed.

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

Commit messages:
 - 8267952: async logging supports to dynamically change tags and decorators

Changes: https://git.openjdk.java.net/jdk/pull/4408/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267952
  Stats: 149 lines in 8 files changed: 139 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408

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

From cjplummer at openjdk.java.net  Tue Jun  8 03:58:20 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 8 Jun 2021 03:58:20 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <MPprUn7AVhUEJ0gPvMqyuvrZ12kOhHOabDbLoRhai8I=.aa8ffee7-5edd-4cc5-97c9-1d24003ce0e8@github.com>

On Tue, 1 Jun 2021 20:52:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

Marked as reviewed by cjplummer (Reviewer).

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

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

From stuefe at openjdk.java.net  Tue Jun  8 04:00:21 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Jun 2021 04:00:21 GMT
Subject: RFR: 8267209: Child threads should defer logging to after
 child-parent handshake
In-Reply-To: <Fljf4ZQecgvpsNWCl9x71fjRZLknD7rXJ_5-pi9kRPw=.b7f99c3b-ecca-4513-ab2e-b8604b5f4e2c@github.com>
References: <PTTD3laXCucd_3IImGQ-y9QgHmvfMlh2zafFAfd06hY=.fcc343b2-a478-4652-8731-a04cc3b9be84@github.com>
 <Fljf4ZQecgvpsNWCl9x71fjRZLknD7rXJ_5-pi9kRPw=.b7f99c3b-ecca-4513-ab2e-b8604b5f4e2c@github.com>
Message-ID: <fsmA_vLr_xVfRx6P0DSYPTlgki-WqjStLwubMZ1pXQo=.9260e49d-4edc-4c8c-8400-ea0f41244584@github.com>

On Wed, 26 May 2021 01:37:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good.

Thanks Coleen and David.

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

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

From stuefe at openjdk.java.net  Tue Jun  8 04:00:22 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Jun 2021 04:00:22 GMT
Subject: Integrated: 8267209: Child threads should defer logging to after
 child-parent handshake
In-Reply-To: <PTTD3laXCucd_3IImGQ-y9QgHmvfMlh2zafFAfd06hY=.fcc343b2-a478-4652-8731-a04cc3b9be84@github.com>
References: <PTTD3laXCucd_3IImGQ-y9QgHmvfMlh2zafFAfd06hY=.fcc343b2-a478-4652-8731-a04cc3b9be84@github.com>
Message-ID: <F8vq5u8jTk2ARQG2SJDiePmgmKn7MQW_W7jbluzPVFk=.040931f0-c682-4e78-98ad-a07fbc635613@github.com>

On Sun, 16 May 2021 06:57:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> May I have reviews for this very simple change (triggered by this ML discussion [1]):
> 
> On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake.
> 
> The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake.
> 
> I ran OPs [1] test on my machine and with logging to a very fast ssd enabled:
> 
> 
> thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest
> Duration: 5191
> 
> 
> with this patch test time drops by about 19%:
> 
> 
> thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest
> Duration: 4228
> 
> 
> No perceptible difference with logging disabled, as it should be.
> 
> ---
> 
> (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.)
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html

This pull request has now been integrated.

Changeset: f40c89e8
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f40c89e8e9fae26da53b5d820d8e64d9b30faf8c
Stats:     12 lines in 2 files changed: 6 ins; 6 del; 0 mod

8267209: Child threads should defer logging to after child-parent handshake

Reviewed-by: dholmes, coleenp

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

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

From iklam at openjdk.java.net  Tue Jun  8 04:34:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Jun 2021 04:34:23 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
 <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
Message-ID: <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>

On Tue, 8 Jun 2021 01:57:29 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> The issue that we encountered recently was with a JVMTI profiling agent. However, we can't conclude from that it is only restricted to JVMTI usages. Since we don't have any evidences to exclude non-JVMTI cases, narrowing down the scope of Coleen's existing comment is not a good idea. Expending the comment with clarifications and example (JVMTI agent) is appropriate at this point.

I have looked at every use of `jmethodID` in jni.cpp. All of them will try to dereference the `Method*` without a NULL check. So any code that tries to invoke JNI calls with a `jmethodID` associated with a deallocated class will crash immediately.

> > I don't think the JNI spec allows invalid jmethodID to be used.
> 
> I haven't found the specific language in the JNI spec. The quoted spec language in updated comment does not strongly indicate that.

See https://docs.oracle.com/en/java/javase/16/docs/specs/jni/design.html

"A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid.
...
The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."

> > Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.
> 
> It's not just JVMTI vs non-JVMTI issues. The JNIMethodBlocks are not always created. When application native code creates (directly or indirectly) jmethod_ids, how does VM know when it's safe to release the memory? It faces the same issue as the JVMTI agent case. [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) addresses from unloading point view. However, that's unsafe either.
> 
> > We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?
> 
> If we update the JNI spec to ban such usages and fix all existing third party code (if we can), we can change the VM to release memory safely. That would be welcomed by developers. However, any unfixed native code would still run into risks of crashes.

>From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.

It's only JVMTI that has the concept of `JVMTI_ERROR_INVALID_METHODID`.  So the only reason of not freeing the `JNIMethodBlock` is because of JVMTI.

However, the concept of  `JVMTI_ERROR_INVALID_METHODID` is inherently unsafe. Even the existing JVMTI implementation is buggy because classes can be deallocated concurrently (ZGC does that):


static jvmtiError JNICALL
jvmti_GetMethodDeclaringClass(jvmtiEnv* env,
            jmethodID method,
            jclass* declaring_class_ptr) {
  ...
  Method* checked_method = Method::checked_resolve_jmethod_id(method);
  if (checked_method == NULL) {
      return JVMTI_ERROR_INVALID_METHODID;
  }
  if (declaring_class_ptr == NULL) {
      return JVMTI_ERROR_NULL_POINTER;
  }

  >>>>>> ZGC concurrently deallocates the class
 
  err = jvmti_env->GetMethodDeclaringClass(checked_method, declaring_class_ptr); >>> will crash


In [JDK-8268088](https://bugs.openjdk.java.net/browse/JDK-8268088), you described a JVMTI-based profiler that "captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders."

This is unsafe and can crash with ZGC even if we don't free the JNIMethodBlocks, because `checked_method` could point to a deallocated `Method`. See more in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).

To handle this correctly, the profiler should ensure that the classes with the collected stacks cannot be GCed. This can be done by creating a GlobalRef on the classloader associated with the jmethodID:

- GetMethodDeclaringClass -> GetClassLoader -> NewGlobalRef

The profiler can release the GlobalRef after it has processed the jmethodID.

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

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

From david.holmes at oracle.com  Tue Jun  8 04:37:41 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Jun 2021 14:37:41 +1000
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v3]
In-Reply-To: <o2GFPbOPZcfXfQlhHasiC8QewbG1lrgar1Tm5WeamUE=.25060f89-3159-4b09-997b-240bb9defaae@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <MOrMreKTYLkXnyWjYlVhSg9TJ8jhUMeGEkeUNkyW3UA=.627df8a4-9e71-4d10-8ef0-5f5d529118e9@github.com>
 <aRYbQEVCv6ISwul_MM_Q1zmY-SPiOdKFoRLMql4CzZM=.68c142ef-9334-4aa6-80df-248aaf266a10@github.com>
 <r0dkWxjbvAWxtkoJbml6-DQKKlrOwM3L46ZXz9siS94=.a1682fb7-2b62-4fbd-91dc-b877b6e165f1@github.com>
 <4acsHdIMOdkmNdinSYJk5tHCij-s7X2IYrF1FGCJ-mw=.0f19020f-cf14-4167-98bc-36dca1d7352b@github.com>
 <d_ZFvpmmlMl0ZzwwsBQurOEi8YQJWBrNBJY
 TThOnYQw=.95855dd9-3935-4413-809c-1beeac1f60cb@github.com>
 <k8KxE-V_7Tl7LLx-di6Oht3Nz1oZYsQiaYyBWnDJkfI=.97fe372f-b257-45b2-89be-c34e0fc2c1db@github.com>
 <J4KDyjpj3HWMsdCldHrY6rAkTcrv3G6q5dGLLDS3-LA=.3c47d259-d7e2-4592-9abd-082aec2d90ee@github.com>
 <3fhWHR3YaOU0XDbH0UTx6xnToWKNwGfPdZkyxYxgiyg=.c5e34807-5f52-4dbc-9093-bed95d79a329@github.com>
 <o2GFPbOPZcfXfQlhHasiC8QewbG1lrgar1Tm5WeamUE=.25060f89-3159-4b09-997b-240bb9defaae@github.com>
Message-ID: <9f50efe9-ebf3-f567-89db-d15baad34e4c@oracle.com>

On 7/06/2021 1:49 pm, Patricio Chilano Mateo wrote:
> On Fri, 4 Jun 2021 22:46:08 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> 
>>> As long as we have a release() fence after the handshake closure the reordering of decrementing _pending_threads and removing the operation from the queue shouldn't matter since the target doesn't read _pending_threads.
>>
>> "release operation: no reads or writes in the current thread can be reordered after this store."
>>
>> But stores happened after this store may be reordered before. Which means the removal might happen even before the handshake operation was executed.
>>
>> So we need to stop the store ("the relaxed CAS") from floating above the dec.
>>
>> Dec with rel+acq gives: "No memory reads or writes in the current thread can be reordered before or after this store."
> 
> By release() fence I was referring to the definition in orderAccess (LoadStore | StoreStore), sorry for the confusion, 

Those "definitions" are not definitions - the semantics of combining 
loadstore|storestore are sufficient to implement release but not 
necessary. If all you have is loadstore and storestore style barriers 
then that combination is what you need to implement release semantics. 
But release semantics (and acquire semantics) are weaker than that.

> which would be enough to prevent any of those writes to float above the barrier. I now see that dec( ,memory_order_release) might not necessarily provide that though so we would need to use OrderAccess::release() + dec( ,memory_order_relaxed) instead. But I see that using a full fence is probably easier to read. Also by looking at the implementations of dec() for arm32/aarch64 it seems the order parameter is ignored (always full fence) (?), which would defeat the purpose of using release().

We should always try to use the correct logical memory barrier for a 
given situation, without too much concern about whether or not a given 
platform can implement "finer-grained" barriers. But on the flip-side if 
proving the correctness of a weaker barrier is difficult to reason about 
(or easily broken by simple code changes) then stick with a coarser 
barrier. Performance issues may sometimes force you in a particular 
direction in any case.

Cheers,
David
-----

> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3973
> 

From ysuenaga at openjdk.java.net  Tue Jun  8 04:44:17 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 8 Jun 2021 04:44:17 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>
Message-ID: <ZnU4kqF_fpKdxldOZV66-TyGSgv5aMPKFkiRX7Al2UQ=.cc5cdfde-23c6-4a28-8c0d-f1f320c6ed05@github.com>

On Mon, 7 Jun 2021 13:44:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> jdk.CPULoad event reports CPU usage.
>> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
>> 
>> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
>> 
>> 
>> public class InfiniteLoop{
>>   public static void main(String[] args){
>>     while(true){
>>     }
>>   }
>> }
>> 
>> 
>> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.
>
> src/hotspot/os/linux/os_perf_linux.cpp line 404:
> 
>> 402:     }
>> 403:     *pkernelLoad *= scale;
>> 404:     user_load *= scale;
> 
> If I read this correctly the cpu load would only be scaled to the number of configured container limits with no bearing of the actual cpu usage of processes within the container. For example: Let process A be running in container A' with X/2 cpus and process B running in container B' with X/2 cpus. X are the total number of cpus available on a host. Then A is using 100% cpu (i.e. `1.0`) and B is being idle (i.e. close to `0.0`). With this patch I'd get a CPU load report of about `1.0` for each container, A' and B'. Am I missing something?
> 
> On the JDK side we have `Metrics.getCpuUsage()` API which isn't present in HotSpot code. I believe we'd have to have a similar API in OSContainer in order to implement this correctly. Thoughts?

Further investigation, I think need to read cpuacct.usage in cgroups v1, or cpu.stat in cgroups v2 when `get_cpu_load()` is called with `CPU_LOAD_GLOBAL` - @jerboaa did you point it out?

Of course I can add it to this PR, but if we work for it, I think we should consolidate implementation - but it may not happen until RDP 1 (and it might be big change).

Hence I will withdraw this PR and will close JBS, is it ok?

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

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

From david.holmes at oracle.com  Tue Jun  8 04:50:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Jun 2021 14:50:03 +1000
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <1ZtcqbSy_wtTLrc7-YruYbqZg3K6SOiZUhjIa5Ca7j8=.8d2be8fa-01ca-4438-b651-77a8a03e6560@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
 <1ZtcqbSy_wtTLrc7-YruYbqZg3K6SOiZUhjIa5Ca7j8=.8d2be8fa-01ca-4438-b651-77a8a03e6560@github.com>
Message-ID: <f62dbd3d-2fa0-cd98-27b4-e6a25c808759@oracle.com>

On 8/06/2021 1:11 pm, Yasumasa Suenaga wrote:
> On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Please review this trivial fix to ensure we do not try to alloca zero bytes.
>>
>> Thanks,
>> David
> 
> Looks good!

Thanks Yasumasa!

David

> -------------
> 
> Marked as reviewed by ysuenaga (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4407
> 

From dholmes at openjdk.java.net  Tue Jun  8 04:56:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 04:56:19 GMT
Subject: Integrated: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
Message-ID: <vOjbfSmeGTVZ7L8nZ5Nfy9gHrXxRbY1rQ-Kq2wmDuoY=.b8069749-879a-4843-b5bf-2228b34f9af0@github.com>

On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to ensure we do not try to alloca zero bytes.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 341f6760
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/341f676066ab807d433f0f0b6c8356d2ad0e1cc9
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8267908: linux: thread_native_entry can scribble on stack frame

Reviewed-by: ysuenaga

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

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

From xliu at openjdk.java.net  Tue Jun  8 05:59:15 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Jun 2021 05:59:15 GMT
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
Message-ID: <UMkjsn1Ba6uiZfTfTWi9ii6jt9trmGCV88kEKmdx18w=.a33800a8-fa50-4323-a087-26921c6cdc29@github.com>

On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to ensure we do not try to alloca zero bytes.
> 
> Thanks,
> David

When random is 1, that store is still safe because c++ std says sizeof char is 1.

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

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

From david.holmes at oracle.com  Tue Jun  8 06:18:21 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Jun 2021 16:18:21 +1000
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <UMkjsn1Ba6uiZfTfTWi9ii6jt9trmGCV88kEKmdx18w=.a33800a8-fa50-4323-a087-26921c6cdc29@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
 <UMkjsn1Ba6uiZfTfTWi9ii6jt9trmGCV88kEKmdx18w=.a33800a8-fa50-4323-a087-26921c6cdc29@github.com>
Message-ID: <f7c1240c-5e5b-e3b4-a9f6-85979fd5a552@oracle.com>

On 8/06/2021 3:59 pm, Xin Liu wrote:
> On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Please review this trivial fix to ensure we do not try to alloca zero bytes.
>>
>> Thanks,
>> David
> 
> When random is 1, that store is still safe because c++ std says sizeof char is 1.

The issue was random being zero.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4407
> 

From xliu at openjdk.java.net  Tue Jun  8 06:32:21 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Jun 2021 06:32:21 GMT
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
Message-ID: <AS1m5dWJWVWDoJWlZlnhqmrezdu4scVXm8OWfmkUrCA=.c9be424f-2337-4008-adce-d69e467f7e6f@github.com>

On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to ensure we do not try to alloca zero bytes.
> 
> Thanks,
> David

I know. you patch LGTM. that is a side note. 

I was worried about this statement was not portable if random is 1. 
`*(char *)stackmem = 1;`

C++ std 6.5.3.4 says: 

When sizeof is applied  to  an  operand  that  has  type char, unsigned  char, or signed  char,  (or  a qualified  version  thereof)  the  result  is  1.


Therefore, it's portable.

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

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

From david.holmes at oracle.com  Tue Jun  8 06:53:09 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Jun 2021 16:53:09 +1000
Subject: RFR: 8267908: linux: thread_native_entry can scribble on stack
 frame
In-Reply-To: <AS1m5dWJWVWDoJWlZlnhqmrezdu4scVXm8OWfmkUrCA=.c9be424f-2337-4008-adce-d69e467f7e6f@github.com>
References: <ls6QmKxrERnl3qeEoogppEAUo3ptJqWrXu6MNH0XXLY=.cc4a2811-17cd-4748-9329-f92bdc3b6200@github.com>
 <AS1m5dWJWVWDoJWlZlnhqmrezdu4scVXm8OWfmkUrCA=.c9be424f-2337-4008-adce-d69e467f7e6f@github.com>
Message-ID: <690ab92c-fd2e-fbe1-5d8b-14970ebcf8b9@oracle.com>

On 8/06/2021 4:32 pm, Xin Liu wrote:
> On Tue, 8 Jun 2021 02:02:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Please review this trivial fix to ensure we do not try to alloca zero bytes.
>>
>> Thanks,
>> David
> 
> I know. you patch LGTM. that is a side note.
> 
> I was worried about this statement was not portable if random is 1.
> `*(char *)stackmem = 1;`
> 
> C++ std 6.5.3.4 says:
> 
> When sizeof is applied  to  an  operand  that  has  type char, unsigned  char, or signed  char,  (or  a qualified  version  thereof)  the  result  is  1.
> 
> 
> Therefore, it's portable.

Yes it is portable - that was never in question. :)

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4407
> 

From xliu at openjdk.java.net  Tue Jun  8 07:23:17 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Jun 2021 07:23:17 GMT
Subject: Integrated: 8268165: AsyncLogging will crash if rotate() fails
In-Reply-To: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
Message-ID: <yQSeljORcPwUiZQsKhryIxlBBp0zAmUco2obRWWm_Pc=.785f8de5-9e88-43b2-975d-6b46fd8a73a4@github.com>

On Thu, 3 Jun 2021 09:39:16 GMT, Xin Liu <xliu at openjdk.org> wrote:

> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing.

This pull request has now been integrated.

Changeset: 81054789
Author:    Xin Liu <xliu at openjdk.org>
Committer: Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81054789a32f29b06f0804e09aabd7cf17464778
Stats:     26 lines in 1 file changed: 19 ins; 4 del; 3 mod

8268165: AsyncLogging will crash if rotate() fails

LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations.  AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check.  Null check is added to prevent from crashing.

Reviewed-by: ysuenaga

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

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

From sgehwolf at openjdk.java.net  Tue Jun  8 08:06:19 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 8 Jun 2021 08:06:19 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <ZnU4kqF_fpKdxldOZV66-TyGSgv5aMPKFkiRX7Al2UQ=.cc5cdfde-23c6-4a28-8c0d-f1f320c6ed05@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>
 <ZnU4kqF_fpKdxldOZV66-TyGSgv5aMPKFkiRX7Al2UQ=.cc5cdfde-23c6-4a28-8c0d-f1f320c6ed05@github.com>
Message-ID: <dpWGVny9i8BsW5ATSgio3NO62f49qd3Dc-yOSV9JZ-s=.bbeaa1cb-8371-4c4f-badc-0eab686a6e22@github.com>

On Tue, 8 Jun 2021 04:41:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/os/linux/os_perf_linux.cpp line 404:
>> 
>>> 402:     }
>>> 403:     *pkernelLoad *= scale;
>>> 404:     user_load *= scale;
>> 
>> If I read this correctly the cpu load would only be scaled to the number of configured container limits with no bearing of the actual cpu usage of processes within the container. For example: Let process A be running in container A' with X/2 cpus and process B running in container B' with X/2 cpus. X are the total number of cpus available on a host. Then A is using 100% cpu (i.e. `1.0`) and B is being idle (i.e. close to `0.0`). With this patch I'd get a CPU load report of about `1.0` for each container, A' and B'. Am I missing something?
>> 
>> On the JDK side we have `Metrics.getCpuUsage()` API which isn't present in HotSpot code. I believe we'd have to have a similar API in OSContainer in order to implement this correctly. Thoughts?
>
> Further investigation, I think need to read cpuacct.usage in cgroups v1, or cpu.stat in cgroups v2 when `get_cpu_load()` is called with `CPU_LOAD_GLOBAL` - @jerboaa did you point it out?
> 
> Of course I can add it to this PR, but if we work for it, I think we should consolidate implementation - but it may not happen until RDP 1 (and it might be big change).
> 
> Hence I will withdraw this PR and will close JBS, is it ok?

@YaSuenag Yes, that's what `Metrics.getCpuUsage()` does under the hood. I'd suggest to first add the `get_cpu_usage()` API to `OSContainer` and then once it's there use it here. Or maybe consolidate things and you'll get away with using the Java API. Either way I'm fine with waiting/withdrawing.

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

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

From ysuenaga at openjdk.java.net  Tue Jun  8 08:26:20 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 8 Jun 2021 08:26:20 GMT
Subject: RFR: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <dpWGVny9i8BsW5ATSgio3NO62f49qd3Dc-yOSV9JZ-s=.bbeaa1cb-8371-4c4f-badc-0eab686a6e22@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
 <6Q6cm4oBecNXSgVSiAMp9KjrZpfgcqRU-3CRvw0FFmw=.11d6360e-149c-4d4c-bf76-7194c3475cff@github.com>
 <ZnU4kqF_fpKdxldOZV66-TyGSgv5aMPKFkiRX7Al2UQ=.cc5cdfde-23c6-4a28-8c0d-f1f320c6ed05@github.com>
 <dpWGVny9i8BsW5ATSgio3NO62f49qd3Dc-yOSV9JZ-s=.bbeaa1cb-8371-4c4f-badc-0eab686a6e22@github.com>
Message-ID: <gezKFAx_ZJV_do60mvI2jXp3h2WaNm2ka7ueU6PNipk=.0661043f-e8e4-492f-aa18-19c6c34ef6a8@github.com>

On Tue, 8 Jun 2021 08:03:42 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Further investigation, I think need to read cpuacct.usage in cgroups v1, or cpu.stat in cgroups v2 when `get_cpu_load()` is called with `CPU_LOAD_GLOBAL` - @jerboaa did you point it out?
>> 
>> Of course I can add it to this PR, but if we work for it, I think we should consolidate implementation - but it may not happen until RDP 1 (and it might be big change).
>> 
>> Hence I will withdraw this PR and will close JBS, is it ok?
>
> @YaSuenag Yes, that's what `Metrics.getCpuUsage()` does under the hood. I'd suggest to first add the `get_cpu_usage()` API to `OSContainer` and then once it's there use it here. Or maybe consolidate things and you'll get away with using the Java API. Either way I'm fine with waiting/withdrawing.

Thanks @jerboaa !
I will withdraw this PR and will close JBS. I hope we will consolidate logics in near future...

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

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

From ysuenaga at openjdk.java.net  Tue Jun  8 08:26:20 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 8 Jun 2021 08:26:20 GMT
Subject: Withdrawn: 8268098: jdk.CPULoad event reports incorrect CPU usage
 inside a container
In-Reply-To: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
References: <VPOqluTGZ8RLjEJFU9yg9JiHSAlEdI0WFpjQe9l92LM=.0506d660-8c66-4512-b485-bbe3f4830b7f@github.com>
Message-ID: <MKW6W23MzW2JsmWh6I_gNGWLQdvbCmH1YBoIW0OSioI=.9484b78e-43c0-4aab-b326-485fe7f6fc23@github.com>

On Wed, 2 Jun 2021 06:59:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jdk.CPULoad event reports CPU usage.
> If JVM runs in a container which is limited CPU resource (quota, shares, cpu), it is incorrect.
> 
> When I ran following program inside a container with `--cpuset-cpu=0,1`, I expected jdk.CPULoad event reports 50%, however it reported 25% because container host has 4 CPUs.
> 
> 
> public class InfiniteLoop{
>   public static void main(String[] args){
>     while(true){
>     }
>   }
> }
> 
> 
> jdk.CPULoad event uses the result from `get_cpu_load()` in os_perf_linux.cpp, but it does not consider cgroups.

This pull request has been closed without being integrated.

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

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

From rehn at openjdk.java.net  Tue Jun  8 08:29:24 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 8 Jun 2021 08:29:24 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v6]
In-Reply-To: <ddj2wV4mjXnMaMdJtDkDhyo30gHdfcmt2a_ClOETDEc=.fda93873-f0c6-45f8-8bcb-af6a17e136cf@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <8yz8b4bqC7aZuAcBC7sFWdL7mTkFc4zDwyAn3Cg-yEU=.089f3a7a-23c8-4e68-aa5c-ffc71d9ee7bd@github.com>
 <ddj2wV4mjXnMaMdJtDkDhyo30gHdfcmt2a_ClOETDEc=.fda93873-f0c6-45f8-8bcb-af6a17e136cf@github.com>
Message-ID: <ihG-r1fnyZx7Z3pP6YTLjcdk_TD5IDGMeTv88YU7bEs=.d1c7010f-c4c0-4be0-a535-2becdc3f947b@github.com>

On Mon, 7 Jun 2021 20:08:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I did a crawl thru review of the v05 full webrev.
> Thumbs up.
> 
> There are a few copyright years that need to be updated.

Thank you!

> src/hotspot/share/utilities/filterQueue.hpp line 68:
> 
>> 66:   // exclusive to other contains and pops calls.
>> 67:   template <typename MATCH_FUNC>
>> 68:   bool contains(MATCH_FUNC& match_func);
> 
> Need to update the copyright for this file.

Fixed

> src/hotspot/share/utilities/filterQueue.inline.hpp line 114:
> 
>> 112:   } while (true);
>> 113: }
>> 114: 
> 
> Need to update the copyright for this file.

Fixed

> test/hotspot/gtest/utilities/test_filterQueue.cpp line 58:
> 
>> 56: static void is_empty(FilterQueue<uintptr_t>& queue) {
>> 57:   EXPECT_EQ(queue.is_empty(), true) << "Must be empty.";
>> 58:   EXPECT_EQ(queue.contains(match_1), false) << "Must be empty.";
> 
> Need to update the copyright for this file.

Fixed

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

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

From rehn at openjdk.java.net  Tue Jun  8 08:46:50 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 8 Jun 2021 08:46:50 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v7]
In-Reply-To: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
Message-ID: <CjJmSSuzNB1ISl2RMrGxY2BEUCyGFlFC2FdmgGsJfqQ=.30026fb7-7a36-4b3b-a50b-19e2bb6c9897@github.com>

> Please consider this change-set which address the issue on hand.
> 
> I identified two problems:
> 
> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
> Fixed by leaving the handshakee being processed in queue until completed.
> And remove looping, since if ever the queue is empty the handshakee may processed.
> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
> 
> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
> 
> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
> Fixed by adding a loadload.
> 
> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
> (real reprod ~1/400 with increased test time)
> If we are updating the poll there should not be an active handshaker.
> The above fixed the issue.
> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
> 
> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
> 
> Passes stressing relevant test on aarch64 and t1-7.
> 
> Thanks, Robbin

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

 - Fixed CW header
 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Added comment
 - Small review updates
 - Merge branch 'master' into handshakee
 - Merge branch 'master' into handshakee
 - Small update
 - Merge branch 'master' into handshakee
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/49e3b586...7a85a13a

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3973/files
  - new: https://git.openjdk.java.net/jdk/pull/3973/files/7277d7a6..7a85a13a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=05-06

  Stats: 19260 lines in 177 files changed: 16816 ins; 1048 del; 1396 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3973.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973

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

From rschmelter at openjdk.java.net  Tue Jun  8 08:53:13 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Tue, 8 Jun 2021 08:53:13 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <_6WT533IoNW8F1rY3zHVSp1aw0lHdpS5ckUtILKb6Sg=.58078d97-02c5-4fc3-ba5e-393cddb81b7e@github.com>

On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows flags (although complied fine)

Looks good, thanks for the change.

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

Marked as reviewed by rschmelter (Committer).

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

From mgronlun at openjdk.java.net  Tue Jun  8 09:38:13 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 8 Jun 2021 09:38:13 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <DyYlfVt6ORpPQ4OIjBPiwvcXBc2NMThgp8KqBkFqr6Y=.729ae9aa-3263-42e2-9f4e-9227f6f76f0d@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
 <DyYlfVt6ORpPQ4OIjBPiwvcXBc2NMThgp8KqBkFqr6Y=.729ae9aa-3263-42e2-9f4e-9227f6f76f0d@github.com>
Message-ID: <a9flVWGcG2pLVG8CtRnkZHyGZAOmxsrSuSlTM1WlKgA=.0742bf0c-2f43-4642-9565-378b29f6bce6@github.com>

On Mon, 7 Jun 2021 20:19:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   read once
>
> Thumbs up.
> 
> Should the `_start` and `_top` fields be marked `volatile` to
> prevent the S390 compiler from "optimizing" like it did with
> another recent bug (JDK-8267842)?

@dcubed-ojdk Thanks Dan for looking at this. Hmm...having to introduce an explicit "volatile" keyword implies the "read-once" promise of Atomic::load() is not sufficient? I was told the side-effects of via Atomic::load(), which makes expressions volatile-qualified, are sufficient for read-once. But maybe not for all platforms?

If "volatile" decorations are required, I would prefer, granted it's sufficient, to only decorate the local variables. Having to decorate the tlab pointers could result in introducing unnecessary ordering constraints, i.e. for the TLAB owner, which could perhaps hurt performance?

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

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

From stuefe at openjdk.java.net  Tue Jun  8 12:15:17 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Jun 2021 12:15:17 GMT
Subject: RFR: 8266891: Provide a switch to force the class space to a
 specific location
In-Reply-To: <io5Mc27eXrepHH1zPzypDZqQrfsF2xVgZLMrIdny64I=.d8cd20f6-ae7f-4e12-af04-a79c64d65c9f@github.com>
References: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
 <io5Mc27eXrepHH1zPzypDZqQrfsF2xVgZLMrIdny64I=.d8cd20f6-ae7f-4e12-af04-a79c64d65c9f@github.com>
Message-ID: <xyOaNwCz4f-1Kx9JoHCGGinqceV2AHqu5Ip6Ib5n69Y=.74083f76-ebe0-491b-a2eb-aecf5c915543@github.com>

On Thu, 27 May 2021 00:44:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This seems good. Small comment. Were you going to add a test or did you want this to test manually?

Thank you Coleen. I'll add a test in a follow up RFE.

> src/hotspot/share/memory/metaspace.cpp line 716:
> 
>> 714:     // this may fail, in which case the VM will exit after printing an appropiate message.
>> 715:     // Tests using this switch should cope with that.
>> 716:     if (!FLAG_IS_DEFAULT(CompressedClassSpaceBaseAddress) && CompressedClassSpaceBaseAddress != 0) {
> 
> Don't you just have to test if CompressedClassSpaceBaseAddress != 0 , since that's the default if not set?

Makes sense, I'll change that.

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

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

From david.holmes at oracle.com  Tue Jun  8 13:00:25 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Jun 2021 23:00:25 +1000
Subject: Integrated: 8268165: AsyncLogging will crash if rotate() fails
In-Reply-To: <yQSeljORcPwUiZQsKhryIxlBBp0zAmUco2obRWWm_Pc=.785f8de5-9e88-43b2-975d-6b46fd8a73a4@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <yQSeljORcPwUiZQsKhryIxlBBp0zAmUco2obRWWm_Pc=.785f8de5-9e88-43b2-975d-6b46fd8a73a4@github.com>
Message-ID: <4ff5360c-4d69-3b55-f57a-c337dee28836@oracle.com>

Xin, Yasumasa,

Please note that non-trivial changes in hotspot code require two reviews 
before integration. [1]

Thanks,
David

[1] https://wiki.openjdk.java.net/display/HotSpot/Pushing+a+HotSpot+change

On 8/06/2021 5:23 pm, Xin Liu wrote:
> On Thu, 3 Jun 2021 09:39:16 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing.
> 
> This pull request has now been integrated.
> 
> Changeset: 81054789
> Author:    Xin Liu <xliu at openjdk.org>
> Committer: Yasumasa Suenaga <ysuenaga at openjdk.org>
> URL:       https://git.openjdk.java.net/jdk/commit/81054789a32f29b06f0804e09aabd7cf17464778
> Stats:     26 lines in 1 file changed: 19 ins; 4 del; 3 mod
> 
> 8268165: AsyncLogging will crash if rotate() fails
> 
> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations.  AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check.  Null check is added to prevent from crashing.
> 
> Reviewed-by: ysuenaga
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4332
> 

From stuefe at openjdk.java.net  Tue Jun  8 13:08:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Jun 2021 13:08:40 GMT
Subject: RFR: 8266891: Provide a switch to force the class space to a
 specific location [v2]
In-Reply-To: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
References: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
Message-ID: <MKfB4f-_vqopui0p1RQlRJYas-QEsGmZxjr1cbBIx_w=.5a4f4d9a-dc74-4d9e-a71a-a00df23c2588@github.com>

> To test compressed Klass pointer encoding and other metaspace interna, it would be nice to be able to force location of the class space to a specific location. This would help with analysis of problems like JDK-8261552 or JDK-8265705 - errors in Klass* encoding/decoding which managed to stay unnoticed for an astonishingly long time.
> 
> For simplicity, it would be sufficient to only have this ability if CDS is disabled (Xshare=off), since CCS allocation is tied to CDS location otherwise and that would be more diffictult to disentangle.

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

  Feedback Coleen

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3969/files
  - new: https://git.openjdk.java.net/jdk/pull/3969/files/532a7287..2d962a24

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

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

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

From coleenp at openjdk.java.net  Tue Jun  8 13:29:17 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 8 Jun 2021 13:29:17 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
 <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
 <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>
Message-ID: <GgbzxCpEDACzOwCOhf38SUf0wZhTbtf-wQe4KwIgMIk=.71886398-22e4-4396-a8a2-7b4f27ff4f1a@github.com>

On Tue, 8 Jun 2021 04:30:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi Ioi, thanks for the thoughts!
>> 
>>> If the issue is specific to JVMTI code only, the comment should reflect that. Currently it seems to suggest that all possible JNI code could use an invalid jmethodID. However, using an invalid jmethodID with JNI APIs such as CallStaticVoidMethod will lead to a crash.
>> 
>> The issue that we encountered recently was with a JVMTI profiling agent. However, we can't conclude from that it is only restricted to JVMTI usages. Since we don't have any evidences to exclude non-JVMTI cases, narrowing down the scope of Coleen's existing comment is not a good idea. Expending the comment with clarifications and example (JVMTI agent) is appropriate at this point.
>> 
>>> I don't think the JNI spec allows invalid jmethodID to be used.
>> 
>> I haven't found the specific language in the JNI spec. The quoted spec language in updated comment does not strongly indicate that.
>> 
>>> 
>>> Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.
>>> 
>> 
>> It's not just JVMTI vs non-JVMTI issues. The JNIMethodBlocks are not always created. When application native code creates (directly or indirectly) jmethod_ids, how does VM know when it's safe to release the memory? It faces the same issue as the JVMTI agent case. https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9 addresses from unloading point view. However, that's unsafe either.
>> 
>>> We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?
>>> 
>> 
>> If we update the JNI spec to ban such usages and fix all existing third party code (if we can), we can change the VM to release memory safely. That would be welcomed by developers. However, any unfixed native code would still run into risks of crashes.
>> 
>>> Lastly, do we have any existing test cases that cover the use of invalid jmethodIDs?
>> 
>> Unfortunately there's no existing test case. It would help prevent the crash in production if we had a test case that caught the issue early. It's a good to-do item in addition to the comment clarification, before looking into a potential longer term solution for the memory leak.
>
>> The issue that we encountered recently was with a JVMTI profiling agent. However, we can't conclude from that it is only restricted to JVMTI usages. Since we don't have any evidences to exclude non-JVMTI cases, narrowing down the scope of Coleen's existing comment is not a good idea. Expending the comment with clarifications and example (JVMTI agent) is appropriate at this point.
> 
> I have looked at every use of `jmethodID` in jni.cpp. All of them will try to dereference the `Method*` without a NULL check. So any code that tries to invoke JNI calls with a `jmethodID` associated with a deallocated class will crash immediately.
> 
>> > I don't think the JNI spec allows invalid jmethodID to be used.
>> 
>> I haven't found the specific language in the JNI spec. The quoted spec language in updated comment does not strongly indicate that.
> 
> See https://docs.oracle.com/en/java/javase/16/docs/specs/jni/design.html
> 
> "A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid.
> ...
> The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."
> 
>> > Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.
>> 
>> It's not just JVMTI vs non-JVMTI issues. The JNIMethodBlocks are not always created. When application native code creates (directly or indirectly) jmethod_ids, how does VM know when it's safe to release the memory? It faces the same issue as the JVMTI agent case. [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) addresses from unloading point view. However, that's unsafe either.
>> 
>> > We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?
>> 
>> If we update the JNI spec to ban such usages and fix all existing third party code (if we can), we can change the VM to release memory safely. That would be welcomed by developers. However, any unfixed native code would still run into risks of crashes.
> 
> From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.
> 
> It's only JVMTI that has the concept of `JVMTI_ERROR_INVALID_METHODID`.  So the only reason of not freeing the `JNIMethodBlock` is because of JVMTI.
> 
> However, the concept of  `JVMTI_ERROR_INVALID_METHODID` is inherently unsafe. Even the existing JVMTI implementation is buggy because classes can be deallocated concurrently (ZGC does that):
> 
> 
> static jvmtiError JNICALL
> jvmti_GetMethodDeclaringClass(jvmtiEnv* env,
>             jmethodID method,
>             jclass* declaring_class_ptr) {
>   ...
>   Method* checked_method = Method::checked_resolve_jmethod_id(method);
>   if (checked_method == NULL) {
>       return JVMTI_ERROR_INVALID_METHODID;
>   }
>   if (declaring_class_ptr == NULL) {
>       return JVMTI_ERROR_NULL_POINTER;
>   }
> 
>   >>>>>> ZGC concurrently deallocates the class
>  
>   err = jvmti_env->GetMethodDeclaringClass(checked_method, declaring_class_ptr); >>> will crash
> 
> 
> In [JDK-8268088](https://bugs.openjdk.java.net/browse/JDK-8268088), you described a JVMTI-based profiler that "captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders."
> 
> This is unsafe and can crash with ZGC even if we don't free the JNIMethodBlocks, because `checked_method` could point to a deallocated `Method`. See more in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).
> 
> To handle this correctly, the profiler should ensure that the classes with the collected stacks cannot be GCed. This can be done by creating a GlobalRef on the classloader associated with the jmethodID:
> 
> - GetMethodDeclaringClass -> GetClassLoader -> NewGlobalRef
> 
> The profiler can release the GlobalRef after it has processed the jmethodID.

I added comments to both of these bugs JDK-8268088 and JDK-8268364.

There are places in the JNI spec that don't specify a "valid method ID" and some places just say "a method ID".  We might be able to fix those.  We will crash for invalid method ID in all the JNI entry points.  There is -Xcheck:jni that does check the method ID though.  Guess I'm repeating my comment above.

As far as the new comment goes, for now, it should include JNI until which time we clarify the spec. I don't see the harm in that.

I was trying to think of a way to check jmethodID with SafeFetch or something to to return JVMTI_ERROR_INVALID_METHODID without running into ABA problems.  Maybe that would work and we can deallocate the jmethodID block.

That said, I never saw the PR  66ef04a and I'd want to review that carefully. My first quick click-through was not positive.  I hid JMethodIDBlocks in method.cpp on purpose!  Plus it seems like a huge change for JDK 11.

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

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

From clanger at openjdk.java.net  Tue Jun  8 13:29:17 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 8 Jun 2021 13:29:17 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <WM1V9wNJsEbDOUELs137pndw7OCCLJUrcpe5PnnGRMw=.058faa39-ff0e-4bac-aa60-7d445a971999@github.com>

On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows flags (although complied fine)

Marked as reviewed by clanger (Reviewer).

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

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

From coleenp at openjdk.java.net  Tue Jun  8 13:38:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 8 Jun 2021 13:38:20 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
Message-ID: <Cpwdd-ozswLjhhQevj-5SSHedvsmJyCg45Zdag91Kx8=.dd8aff16-8f31-4074-a5cb-85c69b8d8d26@github.com>

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

Hi, I put a short comment in JDK-8268088 which I'll expand later.  There's already a JVMTI callback for unloading classes that the user could use to walk the saved jmethodID stacks:

  // notify the debugger
  if (JvmtiExport::should_post_class_unload()) {
    JvmtiExport::post_class_unload(ik);
  }

Otherwise, don't change class  unloading to add a callback because it could be sensitive to safepoints and unsafe places.

My comment in this bug echoes what Ioi said above.  To prevent class unloading, the class mirror should be saved with the Method.  This is the approach taken throughout the vm.  I think hunting down applications that need to fix their profilers may be difficult, but we could add some deprecation messages and warnings (or even an option, which I thought was what you were going to do).  I'm not sure why so many lines are changed in your above pull request.

For now the updated message seems fine to me for JDK 17.

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

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

From ysuenaga at openjdk.java.net  Tue Jun  8 14:09:21 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 8 Jun 2021 14:09:21 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
Message-ID: <gLUy5GDsPzeG-ec28Hi7_B_2VYrfQMUovX6N9aOFQPo=.1c89e178-a95b-4c53-b763-56447d94d013@github.com>

On Fri, 4 Jun 2021 21:08:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8268165
>  - 8268165: AsyncLogging will crash if rotate() fails

Sorry, I will be careful.

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

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

From coleenp at openjdk.java.net  Tue Jun  8 15:21:18 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 8 Jun 2021 15:21:18 GMT
Subject: RFR: 8266891: Provide a switch to force the class space to a
 specific location [v2]
In-Reply-To: <MKfB4f-_vqopui0p1RQlRJYas-QEsGmZxjr1cbBIx_w=.5a4f4d9a-dc74-4d9e-a71a-a00df23c2588@github.com>
References: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
 <MKfB4f-_vqopui0p1RQlRJYas-QEsGmZxjr1cbBIx_w=.5a4f4d9a-dc74-4d9e-a71a-a00df23c2588@github.com>
Message-ID: <k8ORrYtYgItydDUNQfQMMQ_eoXlX7wVtT1hTIaLRlpw=.180051bd-279a-47c8-b8ba-6bd6259b31e1@github.com>

On Tue, 8 Jun 2021 13:08:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> To test compressed Klass pointer encoding and other metaspace interna, it would be nice to be able to force location of the class space to a specific location. This would help with analysis of problems like JDK-8261552 or JDK-8265705 - errors in Klass* encoding/decoding which managed to stay unnoticed for an astonishingly long time.
>> 
>> For simplicity, it would be sufficient to only have this ability if CDS is disabled (Xshare=off), since CCS allocation is tied to CDS location otherwise and that would be more diffictult to disentangle.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Coleen

This update looks good.  Could you do a paranoid short test run (or have you done?) before integrating?  Thanks!
Never mind, I see the git build actions were successful.

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

Marked as reviewed by coleenp (Reviewer).

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

From dcubed at openjdk.java.net  Tue Jun  8 15:37:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Jun 2021 15:37:15 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <oOIS3GK7ADDGUUi1aP6pfYbTNvhuqTBoBV40g5RAAEY=.69892927-09b9-4abf-8a66-391bc2d96be2@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
 <oOIS3GK7ADDGUUi1aP6pfYbTNvhuqTBoBV40g5RAAEY=.69892927-09b9-4abf-8a66-391bc2d96be2@github.com>
Message-ID: <q9gf5N42lXWz1PwuMAWb8-cb8Mc83mJE88XL3RbD06E=.b6e52700-4721-4635-89c3-21b0df4fdf31@github.com>

On Mon, 7 Jun 2021 07:44:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a race-condition and will potentially fail just the same way the bug in #4224 did. There needs to be at least Atomic::loads of the the variables, or the compiler could convert the loads into multiple loads.
>
> @stefank has explained in the bug report why the assertion is not the issue - thanks. So I have to question the validity of just side-stepping the assertion without trying to fix the broken code. What are the implications of finding these broken invariants in the product code? Do we just report/print an incorrect value?

No problem. I believe that @dholmes-ora thinks the bug that we
fixed with JDK-8267842 is a compiler bug for S390.

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

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

From dcubed at openjdk.java.net  Tue Jun  8 16:45:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Jun 2021 16:45:18 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <u1JZ14zEDXVHpXiI1pvJ-1dlqvbG8dyabGZEnYYIxGE=.1a815a1d-8790-4433-8b85-4f6debc1b89c@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>
 <u1JZ14zEDXVHpXiI1pvJ-1dlqvbG8dyabGZEnYYIxGE=.1a815a1d-8790-4433-8b85-4f6debc1b89c@github.com>
Message-ID: <BYeQjqsUxIbvwbe-95f2zmAj-GHbZL6yBQrteM9f8RM=.e4318e83-dd2e-4489-82bd-2b3235121c14@github.com>

On Mon, 7 Jun 2021 17:55:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ping! Any takers?
>> @dholmes-ora and @plummercj - You both reviewed the related test work done in:
>>      JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
>> Any chance you have the cycles for these updates this week?
>
>>  @dholmes-ora and @plummercj - You both reviewed the related test work done in:
>> JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
>> Any chance you have the cycles for these updates this week?
> 
> Yes. Hopefully in the next day or two.

@plummercj  - Thanks for the review!

Any other takers out there?

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

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

From iklam at openjdk.java.net  Tue Jun  8 16:51:18 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Jun 2021 16:51:18 GMT
Subject: RFR: 8248877: Document API contract for MetaspaceObj subtypes [v2]
In-Reply-To: <z0uhn55TMsdK5CeNh4YazWGYdkr-dYxsHxI2-hI4WBo=.90fa44c1-2a65-43a6-b494-c3b84512f91c@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
 <z0uhn55TMsdK5CeNh4YazWGYdkr-dYxsHxI2-hI4WBo=.90fa44c1-2a65-43a6-b494-c3b84512f91c@github.com>
Message-ID: <Ap3V6v7L6Qzvu3uTcG9PNn9nHjGDp25QIKFXHI-goQA=.e55852db-6a69-47f8-9c27-c3f96a4ba398@github.com>

On Thu, 3 Jun 2021 14:15:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments; clean up
>
> Looks good with some minor suggestions.

Thanks @coleenp and @yminqi for the review.

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

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

From iklam at openjdk.java.net  Tue Jun  8 16:51:19 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Jun 2021 16:51:19 GMT
Subject: Integrated: 8248877: Document API contract for MetaspaceObj subtypes
In-Reply-To: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
References: <N-HR0xXfq7WrkB9R2_FUk_mtlPtfzW4X3DDOHm6HtJs=.a73f391b-b178-46ea-9cc5-5ee7f97f9f6f@github.com>
Message-ID: <mIi3IBprJIDO2BqNJjlQiznSiq0ahG2fLFyFDrv_STA=.fe3c7c6a-083a-45cd-949f-505d7a1b8641@github.com>

On Thu, 3 Jun 2021 00:36:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR adds documentation for the (non-virtual) functions that subtypes of MetaspaceObj are required to implement in order for certain templates to work properly. 
> 
> Requested by @rose00 (sorry I took a long time ....).

This pull request has now been integrated.

Changeset: c21cc932
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c21cc932f0a217299689df6c2abcdbc629a668bf
Stats:     15 lines in 1 file changed: 15 ins; 0 del; 0 mod

8248877: Document API contract for MetaspaceObj subtypes

Reviewed-by: coleenp, minqi

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

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

From dcubed at openjdk.java.net  Tue Jun  8 17:17:37 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Jun 2021 17:17:37 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>

> The Thread-SMR project added counter based tests for various APIs.
> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
> 
> Time based tests are more appropriate for stress kits so I'm
> updating the counter based tests to be time based instead.
> 
> Two of the updated tests have shaken out failures that are tracked by:
> 
>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
> 
>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
> 
> These updated tests are tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-5].

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  ProblemList vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java until 8264605 is fixed and vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java until 8266593 is fixed.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4237/files
  - new: https://git.openjdk.java.net/jdk/pull/4237/files/2ab79a2c..5c2633dd

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

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

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

From pchilanomate at openjdk.java.net  Tue Jun  8 17:44:21 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Tue, 8 Jun 2021 17:44:21 GMT
Subject: RFR: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
 [v7]
In-Reply-To: <CjJmSSuzNB1ISl2RMrGxY2BEUCyGFlFC2FdmgGsJfqQ=.30026fb7-7a36-4b3b-a50b-19e2bb6c9897@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
 <CjJmSSuzNB1ISl2RMrGxY2BEUCyGFlFC2FdmgGsJfqQ=.30026fb7-7a36-4b3b-a50b-19e2bb6c9897@github.com>
Message-ID: <c3P0tWQYWkX9ExeDwqViv4gnL7mGNs79ydwK3zbNrWo=.deff193f-bb2e-48b0-8528-086b412c74a7@github.com>

On Tue, 8 Jun 2021 08:46:50 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Fixed CW header
>  - Merge branch 'master' into handshakee
>  - Merge branch 'master' into handshakee
>  - Merge branch 'master' into handshakee
>  - Added comment
>  - Small review updates
>  - Merge branch 'master' into handshakee
>  - Merge branch 'master' into handshakee
>  - Small update
>  - Merge branch 'master' into handshakee
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c00b4e29...7a85a13a

Hi David,

> On 7/06/2021 1:49 pm, Patricio Chilano Mateo wrote:
> 
> > On Fri, 4 Jun 2021 22:46:08 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> > > > As long as we have a release() fence after the handshake closure the reordering of decrementing _pending_threads and removing the operation from the queue shouldn't matter since the target doesn't read _pending_threads.
> > > 
> > > 
> > > "release operation: no reads or writes in the current thread can be reordered after this store."
> > > But stores happened after this store may be reordered before. Which means the removal might happen even before the handshake operation was executed.
> > > So we need to stop the store ("the relaxed CAS") from floating above the dec.
> > > Dec with rel+acq gives: "No memory reads or writes in the current thread can be reordered before or after this store."
> > 
> > 
> > By release() fence I was referring to the definition in orderAccess (LoadStore | StoreStore), sorry for the confusion,
> 
> Those "definitions" are not definitions - the semantics of combining
> loadstore|storestore are sufficient to implement release but not
> necessary. If all you have is loadstore and storestore style barriers
> then that combination is what you need to implement release semantics.
> But release semantics (and acquire semantics) are weaker than that.
> 
I'm talking about standalone fences not the definition of release semantics which is weaker as you pointed out. The equivalent of storeFence from Unsafe.java or std::atomic_thread_fence(std::memory_order_release) with C++ atomics.

Patricio

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

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

From darcy at openjdk.java.net  Tue Jun  8 17:58:43 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Jun 2021 17:58:43 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v6]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <Jc5aI4vVwaRr2ELic0m25VAF77g65HMTE4_T-5JUOlU=.70ed1e0f-3f3c-4d2d-932c-df0c0571037a@github.com>

> 8267630: Start of release updates for JDK 18

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 18 additional commits since the last revision:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Update symbols for JDK 17 b25.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/f12e9650...15479c92

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4175/files
  - new: https://git.openjdk.java.net/jdk/pull/4175/files/34480e50..15479c92

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

  Stats: 5201 lines in 96 files changed: 2786 ins; 1026 del; 1389 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

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

From iklam at openjdk.java.net  Tue Jun  8 18:12:12 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Jun 2021 18:12:12 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
Message-ID: <rcONHF72H4rxHjxHV4gQfauHg2RP2Q_c7mLN0gf1T1c=.a4d62b99-13e3-4b37-a7a0-f55e633397dc@github.com>

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

LGTM

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

Marked as reviewed by iklam (Reviewer).

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

From xliu at openjdk.java.net  Tue Jun  8 19:25:20 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Jun 2021 19:25:20 GMT
Subject: RFR: 8268165: AsyncLogging will crash if rotate() fails [v2]
In-Reply-To: <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
References: <x7R2p-5LMXubmkB2SL6iP57UUanZda9cGpWp30PMNBQ=.d078a1ab-e875-474e-aeda-4ef3c7004211@github.com>
 <hIg-lJA76wtLqUMJCRXXunegiaXs3cx2tPzot-6bm-U=.2e0af95e-3490-4b7e-81e6-e6c610a93a79@github.com>
Message-ID: <--47sFAAFubnQtZslyheSzZNl3DhFF37PvczPHhqw0Q=.51832ea7-f572-4158-8d25-31ee328e1c12@github.com>

On Fri, 4 Jun 2021 21:08:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8268165
>  - 8268165: AsyncLogging will crash if rotate() fails

hi, David, 
I see. I read through that wiki. I will stick with two-reviewers rules in the future.

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

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

From jiangli at openjdk.java.net  Tue Jun  8 19:26:13 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 19:26:13 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <GgbzxCpEDACzOwCOhf38SUf0wZhTbtf-wQe4KwIgMIk=.71886398-22e4-4396-a8a2-7b4f27ff4f1a@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
 <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
 <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>
 <GgbzxCpEDACzOwCOhf38SUf0wZhTbtf-wQe4KwIgMIk=.71886398-22e4-4396-a8a2-7b4f27ff4f1a@github.com>
Message-ID: <SXlHWg91LusYsWIHOqdbgLlxPgTzrPyqA-1Gxg-8Dhs=.2497cfbb-1f3a-4842-8887-49797a9083cc@github.com>

On Tue, 8 Jun 2021 13:25:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> The issue that we encountered recently was with a JVMTI profiling agent. However, we can't conclude from that it is only restricted to JVMTI usages. Since we don't have any evidences to exclude non-JVMTI cases, narrowing down the scope of Coleen's existing comment is not a good idea. Expending the comment with clarifications and example (JVMTI agent) is appropriate at this point.
>> 
>> I have looked at every use of `jmethodID` in jni.cpp. All of them will try to dereference the `Method*` without a NULL check. So any code that tries to invoke JNI calls with a `jmethodID` associated with a deallocated class will crash immediately.
>> 
>>> > I don't think the JNI spec allows invalid jmethodID to be used.
>>> 
>>> I haven't found the specific language in the JNI spec. The quoted spec language in updated comment does not strongly indicate that.
>> 
>> See https://docs.oracle.com/en/java/javase/16/docs/specs/jni/design.html
>> 
>> "A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid.
>> ...
>> The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."
>> 
>>> > Furthermore, we should consider freeing the JNIMethodBlock when JVMTI is not enabled, so we can avoid the memory leak.
>>> 
>>> It's not just JVMTI vs non-JVMTI issues. The JNIMethodBlocks are not always created. When application native code creates (directly or indirectly) jmethod_ids, how does VM know when it's safe to release the memory? It faces the same issue as the JVMTI agent case. [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) addresses from unloading point view. However, that's unsafe either.
>>> 
>>> > We may even want to update the JVMTI spec to disallow invalid jmethodID, but will that introduce incompatibility with 3rd party code?
>>> 
>>> If we update the JNI spec to ban such usages and fix all existing third party code (if we can), we can change the VM to release memory safely. That would be welcomed by developers. However, any unfixed native code would still run into risks of crashes.
>> 
>> From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.
>> 
>> It's only JVMTI that has the concept of `JVMTI_ERROR_INVALID_METHODID`.  So the only reason of not freeing the `JNIMethodBlock` is because of JVMTI.
>> 
>> However, the concept of  `JVMTI_ERROR_INVALID_METHODID` is inherently unsafe. Even the existing JVMTI implementation is buggy because classes can be deallocated concurrently (ZGC does that):
>> 
>> 
>> static jvmtiError JNICALL
>> jvmti_GetMethodDeclaringClass(jvmtiEnv* env,
>>             jmethodID method,
>>             jclass* declaring_class_ptr) {
>>   ...
>>   Method* checked_method = Method::checked_resolve_jmethod_id(method);
>>   if (checked_method == NULL) {
>>       return JVMTI_ERROR_INVALID_METHODID;
>>   }
>>   if (declaring_class_ptr == NULL) {
>>       return JVMTI_ERROR_NULL_POINTER;
>>   }
>> 
>>   >>>>>> ZGC concurrently deallocates the class
>>  
>>   err = jvmti_env->GetMethodDeclaringClass(checked_method, declaring_class_ptr); >>> will crash
>> 
>> 
>> In [JDK-8268088](https://bugs.openjdk.java.net/browse/JDK-8268088), you described a JVMTI-based profiler that "captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders."
>> 
>> This is unsafe and can crash with ZGC even if we don't free the JNIMethodBlocks, because `checked_method` could point to a deallocated `Method`. See more in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).
>> 
>> To handle this correctly, the profiler should ensure that the classes with the collected stacks cannot be GCed. This can be done by creating a GlobalRef on the classloader associated with the jmethodID:
>> 
>> - GetMethodDeclaringClass -> GetClassLoader -> NewGlobalRef
>> 
>> The profiler can release the GlobalRef after it has processed the jmethodID.
>
> I added comments to both of these bugs JDK-8268088 and JDK-8268364.
> 
> There are places in the JNI spec that don't specify a "valid method ID" and some places just say "a method ID".  We might be able to fix those.  We will crash for invalid method ID in all the JNI entry points.  There is -Xcheck:jni that does check the method ID though.  Guess I'm repeating my comment above.
> 
> As far as the new comment goes, for now, it should include JNI until which time we clarify the spec. I don't see the harm in that.
> 
> I was trying to think of a way to check jmethodID with SafeFetch or something to to return JVMTI_ERROR_INVALID_METHODID without running into ABA problems.  Maybe that would work and we can deallocate the jmethodID block.
> 
> That said, I never saw the PR  66ef04a and I'd want to review that carefully. My first quick click-through was not positive.  I hid JMethodIDBlocks in method.cpp on purpose!  Plus it seems like a huge change for JDK 11.

> See https://docs.oracle.com/en/java/javase/16/docs/specs/jni/design.html
> 
> "A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid.
> ...
> The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."

I had read the first quoted text in "Accessing Fields and Methods" when looking into the spec. It states that the method ID becomes invalid after class unloading, but the VM&JNI implementation has tolerated the invalid ID usages after unloading for long time. The second one that you quoted from "Reporting Programming Errors" has stronger language regarding the usages of illegal pointers. It would be good to clarify the language in  "Accessing Fields and Methods" to not allow the usage of the invalid IDs after class unloading. 

> From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.

Today's implementation can tolerate the 'invalid' jemthod_ids usages after unloading (by not releasing the memory). 

> In [JDK-8268088](https://bugs.openjdk.java.net/browse/JDK-8268088), you described a JVMTI-based profiler that "captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders."
> 
> This is unsafe and can crash with ZGC even if we don't free the JNIMethodBlocks, because `checked_method` could point to a deallocated `Method`. See more in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).

Agreed, that would become unsafe when we change to release memory for JNIMethodBlock and JNIMethodBlockNodes with unloaded classes. Thanks for filing [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).

> To handle this correctly, the profiler should ensure that the classes with the collected stacks cannot be GCed. This can be done by creating a GlobalRef on the classloader associated with the jmethodID:
> 
> * GetMethodDeclaringClass -> GetClassLoader -> NewGlobalRef
> 
> The profiler can release the GlobalRef after it has processed the jmethodID.

I would be very cautious to recommend this practice. I added some comments in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364):

That would keep more memory for longer time. The agent behavior would dictate the memory usages of the VM and prevent classes from being unloaded unnecessarily. If an agent only processes all jmethod_ids at the end, it would keep all loaders alive without being able to be unloaded. Also, a bug (fail to release any of the GoabalRef) in the agent might cause memory leaks.

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

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

From jiangli at openjdk.java.net  Tue Jun  8 20:04:14 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 20:04:14 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <Cpwdd-ozswLjhhQevj-5SSHedvsmJyCg45Zdag91Kx8=.dd8aff16-8f31-4074-a5cb-85c69b8d8d26@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <Cpwdd-ozswLjhhQevj-5SSHedvsmJyCg45Zdag91Kx8=.dd8aff16-8f31-4074-a5cb-85c69b8d8d26@github.com>
Message-ID: <sJttxphJ1vMb6rebg_ixNNI7TvRBM1pvjakm3cLuKCM=.5c723a41-11db-4031-a3cb-fa43f2bda67d@github.com>

On Tue, 8 Jun 2021 13:34:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi, I put a short comment in JDK-8268088 which I'll expand later. There's already a JVMTI callback for unloading classes that the user could use to walk the saved jmethodID stacks:
> 
> // notify the debugger
> if (JvmtiExport::should_post_class_unload()) {
> JvmtiExport::post_class_unload(ik);
> }
> 
> Otherwise, don't change class unloading to add a callback because it could be sensitive to safepoints and unsafe places.

A new capability as Ioi suggested in https://bugs.openjdk.java.net/browse/JDK-8268364?focusedCommentId=14426310&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14426310 would be better than using the existing callback for unloading. The possible approach that I described in https://bugs.openjdk.java.net/browse/JDK-8268088?focusedCommentId=14424635&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14424635 also looks for the same direction (however there are still other issues as described in the bug comment).  Also, we need a good strategy for existing code that expects the current behavior. 

> 
> My comment in this bug echoes what Ioi said above. To prevent class unloading, the class mirror should be saved with the Method. This is the approach taken throughout the vm. I think hunting down applications that need to fix their profilers may be difficult, but we could add some deprecation messages and warnings (or even an option, which I thought was what you were going to do).
> 

Prevent or defer class unloading would keep more memory for longer time. It could cause other unwanted side-effects. 

> I'm not sure why so many lines are changed in your above pull request.

Do you refer to https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9? That's based on my internal change on JDK 11 (with other local changes). I restructured code by moving JNIMethodBlock and JNIMethodBlockNodes class declarations to the header file. That's needed to trigger destructor properly from classLoaderData.cpp. The original logic was kept the same, and only the code was being moved around. 

I opened my internal change for reference purposes and assisting the discussions to address the memory leak.

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

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

From jiangli at openjdk.java.net  Tue Jun  8 20:04:15 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 20:04:15 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <rcONHF72H4rxHjxHV4gQfauHg2RP2Q_c7mLN0gf1T1c=.a4d62b99-13e3-4b37-a7a0-f55e633397dc@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <rcONHF72H4rxHjxHV4gQfauHg2RP2Q_c7mLN0gf1T1c=.a4d62b99-13e3-4b37-a7a0-f55e633397dc@github.com>
Message-ID: <ITwVtMQCu8y-88eoxPdsrA6UdjTc1FzAZx4q7A_ZsY0=.629535ef-ab4c-4b2e-a6f5-2c014dfeea61@github.com>

On Tue, 8 Jun 2021 18:09:34 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> LGTM

Thanks for the review!

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

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

From jiangli at openjdk.java.net  Tue Jun  8 20:34:15 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 20:34:15 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <SXlHWg91LusYsWIHOqdbgLlxPgTzrPyqA-1Gxg-8Dhs=.2497cfbb-1f3a-4842-8887-49797a9083cc@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
 <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
 <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>
 <GgbzxCpEDACzOwCOhf38SUf0wZhTbtf-wQe4KwIgMIk=.71886398-22e4-4396-a8a2-7b4f27ff4f1a@github.com>
 <SXlHWg91LusYsWIHOqdbgLlxPgTzrPyqA-1
 Gxg-8Dhs=.2497cfbb-1f3a-4842-8887-49797a9083cc@github.com>
Message-ID: <c0qYcyl8XZbj4-PN2GrVkiiSN9jTYcPfXL_fNJwgiN8=.a27f02d1-6105-4173-8edf-1f8562993ea8@github.com>

On Tue, 8 Jun 2021 19:23:35 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> I added comments to both of these bugs JDK-8268088 and JDK-8268364.
>> 
>> There are places in the JNI spec that don't specify a "valid method ID" and some places just say "a method ID".  We might be able to fix those.  We will crash for invalid method ID in all the JNI entry points.  There is -Xcheck:jni that does check the method ID though.  Guess I'm repeating my comment above.
>> 
>> As far as the new comment goes, for now, it should include JNI until which time we clarify the spec. I don't see the harm in that.
>> 
>> I was trying to think of a way to check jmethodID with SafeFetch or something to to return JVMTI_ERROR_INVALID_METHODID without running into ABA problems.  Maybe that would work and we can deallocate the jmethodID block.
>> 
>> That said, I never saw the PR  66ef04a and I'd want to review that carefully. My first quick click-through was not positive.  I hid JMethodIDBlocks in method.cpp on purpose!  Plus it seems like a huge change for JDK 11.
>
>> See https://docs.oracle.com/en/java/javase/16/docs/specs/jni/design.html
>> 
>> "A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid.
>> ...
>> The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."
> 
> I had read the first quoted text in "Accessing Fields and Methods" when looking into the spec. It states that the method ID becomes invalid after class unloading, but the VM&JNI implementation has tolerated the invalid ID usages after unloading for long time. The second one that you quoted from "Reporting Programming Errors" has stronger language regarding the usages of illegal pointers. It would be good to clarify the language in  "Accessing Fields and Methods" to not allow the usage of the invalid IDs after class unloading. 
> 
>> From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.
> 
> Today's implementation can tolerate the 'invalid' jemthod_ids usages after unloading (by not releasing the memory). 
> 
>> In [JDK-8268088](https://bugs.openjdk.java.net/browse/JDK-8268088), you described a JVMTI-based profiler that "captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders."
>> 
>> This is unsafe and can crash with ZGC even if we don't free the JNIMethodBlocks, because `checked_method` could point to a deallocated `Method`. See more in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).
> 
> Agreed, that would become unsafe when we change to release memory for JNIMethodBlock and JNIMethodBlockNodes with unloaded classes. Thanks for filing [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).
> 
>> To handle this correctly, the profiler should ensure that the classes with the collected stacks cannot be GCed. This can be done by creating a GlobalRef on the classloader associated with the jmethodID:
>> 
>> * GetMethodDeclaringClass -> GetClassLoader -> NewGlobalRef
>> 
>> The profiler can release the GlobalRef after it has processed the jmethodID.
> 
> I would be very cautious to recommend this practice. I added some comments in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364):
> 
> That would keep more memory for longer time. The agent behavior would dictate the memory usages of the VM and prevent classes from being unloaded unnecessarily. If an agent only processes all jmethod_ids at the end, it would keep all loaders alive without being able to be unloaded. Also, a bug (fail to release any of the GoabalRef) in the agent might cause memory leaks.

> There is -Xcheck:jni that does check the method ID though. Guess I'm repeating my comment above.

-Xcheck:jni is not enabled commonly during testing due to other issues. Catching the issue with -Xcheck:jni before production would help (this case does make it more important to enable -Xcheck:jni).

> 
> As far as the new comment goes, for now, it should include JNI until which time we clarify the spec. I don't see the harm in that.
> 

Agreed.

> That said, I never saw the PR [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) and I'd want to review that carefully. My first quick click-through was not positive. 

I opened PR [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) mainly for reference purpose for now. Please don't spend much time reviewing yet :), since we need to address the invalid jmethod_id usages first.
 
> I hid JMethodIDBlocks in method.cpp on purpose! Plus it seems like a huge change for JDK 11.

I moved JNIMethodBlock and JNIMethodBlockNodes class declarations to method.hpp to trigger destructor properly from classLoaderData.cpp in [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9). I made the change as an internal fix and intended to only contribute it to JDK head if there was no issue.

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

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

From jiangli at openjdk.java.net  Tue Jun  8 20:38:18 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 20:38:18 GMT
Subject: Integrated: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData()
In-Reply-To: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
Message-ID: <hTZBB8aV0gdFWhBQS7dRMQk0omvt8qou67DYPmbfSWA=.604961df-9458-4f73-8730-0f4d6e1c2ff7@github.com>

On Mon, 7 Jun 2021 03:31:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.

This pull request has now been integrated.

Changeset: ae160529
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ae16052951fbff21abf02271b761055cd2eed14b
Stats:     11 lines in 1 file changed: 5 ins; 0 del; 6 mod

8268088: Clarify Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData()

Reviewed-by: iklam

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

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

From iklam at openjdk.java.net  Tue Jun  8 21:03:16 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Jun 2021 21:03:16 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <c0qYcyl8XZbj4-PN2GrVkiiSN9jTYcPfXL_fNJwgiN8=.a27f02d1-6105-4173-8edf-1f8562993ea8@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
 <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
 <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>
 <GgbzxCpEDACzOwCOhf38SUf0wZhTbtf-wQe4KwIgMIk=.71886398-22e4-4396-a8a2-7b4f27ff4f1a@github.com>
 <SXlHWg91LusYsWIHOqdbgLlxPgTzrPyqA-1
 Gxg-8Dhs=.2497cfbb-1f3a-4842-8887-49797a9083cc@github.com>
 <c0qYcyl8XZbj4-PN2GrVkiiSN9jTYcPfXL_fNJwgiN8=.a27f02d1-6105-4173-8edf-1f8562993ea8@github.com>
Message-ID: <urZeVXZ9Q6JMEtaArzyHZOEmDB0ae73DPUg8m5_txOg=.8e8a0744-fe30-4323-a473-a0da2180e52e@github.com>

On Tue, 8 Jun 2021 20:31:14 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> See https://docs.oracle.com/en/java/javase/16/docs/specs/jni/design.html
>>> 
>>> "A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid.
>>> ...
>>> The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."
>> 
>> I had read the first quoted text in "Accessing Fields and Methods" when looking into the spec. It states that the method ID becomes invalid after class unloading, but the VM&JNI implementation has tolerated the invalid ID usages after unloading for long time. The second one that you quoted from "Reporting Programming Errors" has stronger language regarding the usages of illegal pointers. It would be good to clarify the language in  "Accessing Fields and Methods" to not allow the usage of the invalid IDs after class unloading. 
>> 
>>> From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.
>> 
>> Today's implementation can tolerate the 'invalid' jemthod_ids usages after unloading (by not releasing the memory). 
>> 
>>> In [JDK-8268088](https://bugs.openjdk.java.net/browse/JDK-8268088), you described a JVMTI-based profiler that "captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders."
>>> 
>>> This is unsafe and can crash with ZGC even if we don't free the JNIMethodBlocks, because `checked_method` could point to a deallocated `Method`. See more in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).
>> 
>> Agreed, that would become unsafe when we change to release memory for JNIMethodBlock and JNIMethodBlockNodes with unloaded classes. Thanks for filing [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364).
>> 
>>> To handle this correctly, the profiler should ensure that the classes with the collected stacks cannot be GCed. This can be done by creating a GlobalRef on the classloader associated with the jmethodID:
>>> 
>>> * GetMethodDeclaringClass -> GetClassLoader -> NewGlobalRef
>>> 
>>> The profiler can release the GlobalRef after it has processed the jmethodID.
>> 
>> I would be very cautious to recommend this practice. I added some comments in [JDK-8268364](https://bugs.openjdk.java.net/browse/JDK-8268364):
>> 
>> That would keep more memory for longer time. The agent behavior would dictate the memory usages of the VM and prevent classes from being unloaded unnecessarily. If an agent only processes all jmethod_ids at the end, it would keep all loaders alive without being able to be unloaded. Also, a bug (fail to release any of the GoabalRef) in the agent might cause memory leaks.
>
>> There is -Xcheck:jni that does check the method ID though. Guess I'm repeating my comment above.
> 
> -Xcheck:jni is not enabled commonly during testing due to other issues. Catching the issue with -Xcheck:jni before production would help (this case does make it more important to enable -Xcheck:jni).
> 
>> 
>> As far as the new comment goes, for now, it should include JNI until which time we clarify the spec. I don't see the harm in that.
>> 
> 
> Agreed.
> 
>> That said, I never saw the PR [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) and I'd want to review that carefully. My first quick click-through was not positive. 
> 
> I opened PR [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) mainly for reference purpose for now. Please don't spend much time reviewing yet :), since we need to address the invalid jmethod_id usages first.
>  
>> I hid JMethodIDBlocks in method.cpp on purpose! Plus it seems like a huge change for JDK 11.
> 
> I moved JNIMethodBlock and JNIMethodBlockNodes class declarations to method.hpp to trigger destructor properly from classLoaderData.cpp in [66ef04a](https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9). I made the change as an internal fix and intended to only contribute it to JDK head if there was no issue.

> > From above, we can conclude that both the JNI spec and implementation disallow the use of invalid jmethodIDs. No existing code 3rd party JNI code can run with invalid jmethodIDs without crashing.
> 
> Today's implementation can tolerate the 'invalid' jemthod_ids usages after unloading (by not releasing the memory).

Today's JNI implementation in HotSpot does not in any way tolerate such invalid jmethodIDs. If an invalid jmethodID is passed to any APIs declared in jni.h, the VM will crash immediately. Please see [JDK-8268406](https://bugs.openjdk.java.net/browse/JDK-8268406) for more details.

It's only JVMTI that tolerates invalid jmethodIDs.

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

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

From jiangli at openjdk.java.net  Tue Jun  8 21:27:21 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Tue, 8 Jun 2021 21:27:21 GMT
Subject: RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related
 comments in ClassLoaderData::~ClassLoaderData() [v2]
In-Reply-To: <urZeVXZ9Q6JMEtaArzyHZOEmDB0ae73DPUg8m5_txOg=.8e8a0744-fe30-4323-a473-a0da2180e52e@github.com>
References: <HwYiMkbcZ1c2rhy0Uktd3Bg_0UsbvzZmvqqm3BG1SSI=.78927cee-fae2-4c00-9320-6c7270a555ef@github.com>
 <SXnKGTy10q9aZZgDkWnfFRKjAmVd6SG_jMySznJIZjM=.ef4ed841-05e5-4f3a-ae81-e05d3ef64b15@github.com>
 <4iloMOQUUP6GMjOta1TNNvltF_xwuy63zn48xdqP-To=.84b1cac7-36e4-4977-9949-578d794ed5d4@github.com>
 <JdJB9MlyRwubRNKT2PdXL3sN4RDgzVUabzMKR0kV8CY=.ab9c417e-ae88-48b9-b612-1bbb024f49df@github.com>
 <iXpTD_o1k0-bUmE9cxvyMQkac_DP1kF5T1lZCmp-dAM=.d6d100ea-5d7e-44ab-8af4-d4c27a67d8ef@github.com>
 <C7XqOqr48X5mYHhAlPVhq-_fxg-3l4ebMuqKb0NhyPk=.8afd9801-a8f4-4266-b4e9-caba6b3e8d2c@github.com>
 <WbmVBsULURtTAjLtFo28n10iax2hh46CrDUP6XTn33Q=.07b0d210-de3c-4b75-a89d-62610258b270@github.com>
 <PaRIydUwn-0tGF-mm1CJ58N-C_HvZ5-PbJCQSUEood8=.21a354a3-5767-4dbb-bdce-1ed129e253e4@github.com>
 <Vu96nnM1kg2WVoC0OxQODS5jIAoNfB7Lj-OMNFzvHHY=.09dc1b82-9cdb-465e-86d6-12bd0ded60df@github.com>
 <GgbzxCpEDACzOwCOhf38SUf0wZhTbtf-wQe4KwIgMIk=.71886398-22e4-4396-a8a2-7b4f27ff4f1a@github.com>
 <SXlHWg91LusYsWIHOqdbgLlxPgTzrPyqA-1
 Gxg-8Dhs=.2497cfbb-1f3a-4842-8887-49797a9083cc@github.com>
 <c0qYcyl8XZbj4-PN2GrVkiiSN9jTYcPfXL_fNJwgiN8=.a27f02d1-6105-4173-8edf-1f8562993ea8@github.com>
 <urZeVXZ9Q6JMEtaArzyHZOEmDB0ae73DPUg8m5_txOg=.8e8a0744-fe30-4323-a473-a0da2180e52e@github.com>
Message-ID: <3POQ1LV86Y3gwbljOraVmmchdKHMHJ_BVrK6P1Sq6JI=.7ecf8ba8-12df-408d-87c2-02448cd5a856@github.com>

On Tue, 8 Jun 2021 21:00:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Today's JNI implementation in HotSpot does not in any way tolerate such invalid jmethodIDs. If an invalid jmethodID is passed to any APIs declared in jni.h, the VM will crash immediately. Please see [JDK-8268406](https://bugs.openjdk.java.net/browse/JDK-8268406) for more details.
> 
> It's only JVMTI that tolerates invalid jmethodIDs.

Thanks for checking into that! That narrows the issue, which is good.

I also created [JDK-8268416](https://bugs.openjdk.java.net/browse/JDK-8268416) for clarifying the spec.

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

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

From minqi at openjdk.java.net  Tue Jun  8 21:50:17 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 8 Jun 2021 21:50:17 GMT
Subject: RFR: 8267556: Enhance class paths check during runtime
In-Reply-To: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
References: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
Message-ID: <Tt-S8l8nd4d6NTfOZnvbCH5rjg0M0PTHzv3c_kdEW-Y=.1e86369e-78b5-48c8-b7b6-fcb70bff0b66@github.com>

On Mon, 7 Jun 2021 23:09:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During CDS dump time, if an entry in the classpath isn't a jar file, the entry will not be recorded in the archive header. However, during runtime, it attempts to compare all the entries in the classpath against the entries from the archive header. The loading of CDS archive would fail if there exists an non-jar entry in the classpath.
> 
> The proposed patch addresses the above issue. It adds a `bool _has_non_jar_in_classpath` to indicate if a non-jar entry has been encountered during dump time in the archive header. This is to minimize the performance impact for the usual cases where there is no non-jar entry in the classpath.
> 
> - [x] mach5 tiers 1 - 4 (including the new test)
> 
> This is targeted for JDK18.

LGTM.

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

Marked as reviewed by minqi (Reviewer).

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

From psandoz at openjdk.java.net  Tue Jun  8 23:35:29 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 8 Jun 2021 23:35:29 GMT
Subject: RFR: 8268353: Test libsvml.so is and is not present in jdk image
Message-ID: <VMlYhPaPnz1Kq4XyHYUYfyWjOfqbzE0ox4LzVn4cQHU=.bc57df75-0e51-42c8-9a90-8d318a700a06@github.com>

Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

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

Commit messages:
 - Improve test.
 - Test for linux and windows
 - 8268353: Test libsvml.so is and is not present in jdk image

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

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

From dholmes at openjdk.java.net  Wed Jun  9 01:55:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 01:55:16 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>
Message-ID: <9XZwKF1ewPtfgMAoVxuetYqllxp_hJmjhoQRnTR_dxQ=.db6b1c69-7753-4b38-96b8-22d1250940e3@github.com>

On Tue, 8 Jun 2021 17:17:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The Thread-SMR project added counter based tests for various APIs.
>> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
>> 
>> Time based tests are more appropriate for stress kits so I'm
>> updating the counter based tests to be time based instead.
>> 
>> Two of the updated tests have shaken out failures that are tracked by:
>> 
>>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
>> 
>>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
>> 
>> These updated tests are tested via Mach5 Tier[134567].
>> They have also been test by my Stress Kit runs for jdk-17+2[0-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ProblemList vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java until 8264605 is fixed and vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java until 8266593 is fixed.

Hi Dan,

This all seems okay. Sorry it took so long to get to it.

Note: All the usage() calls are indented incorrectly.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Wed Jun  9 01:55:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 01:55:17 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <KUaHMvSSDqarKQtc0buxns-LjQlWiC9XZhbXwh0ebKo=.2fd9fa98-8ca2-4f12-a5f1-0dc7902ecfbd@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>
 <KUaHMvSSDqarKQtc0buxns-LjQlWiC9XZhbXwh0ebKo=.2fd9fa98-8ca2-4f12-a5f1-0dc7902ecfbd@github.com>
Message-ID: <Y0IZ8vUVUjvB6zUZTDEuyLcq_1-8OVBVrdgSMJeNTkM=.e79ab9fc-9732-44d1-84a2-a4be19e958e9@github.com>

On Mon, 7 Jun 2021 23:50:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:
>> 
>>> 100:         /*
>>> 101:          * Using printf() instead of NSK_DISPLAY1() in this loop
>>> 102:          * in order to slow down the rate of SuspendThread() calls.
>> 
>> I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.
>
> I couldn't remember why I did that when I wrote the test so
> I removed it.

Maybe to allow the resume to get the thread back into real code before the next suspend hits?

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

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

From dholmes at openjdk.java.net  Wed Jun  9 02:10:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 02:10:23 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v6]
In-Reply-To: <Jc5aI4vVwaRr2ELic0m25VAF77g65HMTE4_T-5JUOlU=.70ed1e0f-3f3c-4d2d-932c-df0c0571037a@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
 <Jc5aI4vVwaRr2ELic0m25VAF77g65HMTE4_T-5JUOlU=.70ed1e0f-3f3c-4d2d-932c-df0c0571037a@github.com>
Message-ID: <owSnOGznbOufzVSeguARFu0r1yo8ZKbiEPMDSkJJI3k=.4fd8cade-0eda-4429-9ab3-7424df9d70f7@github.com>

On Tue, 8 Jun 2021 17:58:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8267630: Start of release updates for JDK 18
>
> 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Update symbols for JDK 17 b25.
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/edba5b0d...15479c92

Looks good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From darcy at openjdk.java.net  Wed Jun  9 03:26:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 9 Jun 2021 03:26:33 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v7]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <jgSeokAAg6w8vLTxtQp4Ouij6W5UUF1os5Tu89B_3T4=.38764bc3-6d88-456e-bacd-ba204069890c@github.com>

> 8267630: Start of release updates for JDK 18

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Update symbols for JDK 17 b25.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/51e8201e...ee6bd4de

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

Changes: https://git.openjdk.java.net/jdk/pull/4175/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=06
  Stats: 5334 lines in 63 files changed: 5292 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

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

From stuefe at openjdk.java.net  Wed Jun  9 04:09:20 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Jun 2021 04:09:20 GMT
Subject: Integrated: 8266891: Provide a switch to force the class space to a
 specific location
In-Reply-To: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
References: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
Message-ID: <FXj_--SoSkx9MhYzywSU34qVSIZFZGUyrfNwl-_1uTg=.627c43d1-1528-43f0-abb6-220e580daa44@github.com>

On Tue, 11 May 2021 08:52:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> To test compressed Klass pointer encoding and other metaspace interna, it would be nice to be able to force location of the class space to a specific location. This would help with analysis of problems like JDK-8261552 or JDK-8265705 - errors in Klass* encoding/decoding which managed to stay unnoticed for an astonishingly long time.
> 
> For simplicity, it would be sufficient to only have this ability if CDS is disabled (Xshare=off), since CCS allocation is tied to CDS location otherwise and that would be more diffictult to disentangle.

This pull request has now been integrated.

Changeset: c9dbc4f0
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c9dbc4f034c765627a2f2f80bb184746be1f2657
Stats:     58 lines in 2 files changed: 43 ins; 10 del; 5 mod

8266891: Provide a switch to force the class space to a specific location

Reviewed-by: iklam, coleenp

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

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

From stuefe at openjdk.java.net  Wed Jun  9 04:09:20 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Jun 2021 04:09:20 GMT
Subject: RFR: 8266891: Provide a switch to force the class space to a
 specific location [v2]
In-Reply-To: <k8ORrYtYgItydDUNQfQMMQ_eoXlX7wVtT1hTIaLRlpw=.180051bd-279a-47c8-b8ba-6bd6259b31e1@github.com>
References: <Psh3mA2FIyt0x2WXw7eeYiiq07WblG8hb2Qleu4YTUE=.525458ee-be9e-4353-992a-8beb1d40f053@github.com>
 <MKfB4f-_vqopui0p1RQlRJYas-QEsGmZxjr1cbBIx_w=.5a4f4d9a-dc74-4d9e-a71a-a00df23c2588@github.com>
 <k8ORrYtYgItydDUNQfQMMQ_eoXlX7wVtT1hTIaLRlpw=.180051bd-279a-47c8-b8ba-6bd6259b31e1@github.com>
Message-ID: <ztmXL1m3euaMUPTwa3ZA4Xal0mWO-3fzQcoY313CaR0=.4ad1c24d-0fc0-4f63-9fc8-bb05d6d3f755@github.com>

On Tue, 8 Jun 2021 15:17:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This update looks good. Could you do a paranoid short test run (or have you done?) before integrating? Thanks!
> Never mind, I see the git build actions were successful.

Thank you Coleen!

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

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

From dholmes at openjdk.java.net  Wed Jun  9 04:44:12 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 04:44:12 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>

On Tue, 8 Jun 2021 03:10:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

src/hotspot/share/logging/logConfiguration.cpp line 268:

> 266:   //
> 267:   // LogDecorator is a set of decorators represented in a uint. sizeof(uint) is not greater than a machine word,
> 268:   // so store of it is atomic on the mainstream processors. I.e. readers see either its older value or new value.

This is not necessarily true - the field also has to have correct alignment to ensure atomic accesses. The convention we are adopting is that all racily accessed fields like _decorators should be declared volatile, and accessed using Atomic::load and Atomic::store.

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

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

From dholmes at openjdk.java.net  Wed Jun  9 04:51:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 04:51:15 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>

On Tue, 8 Jun 2021 03:10:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

src/hotspot/share/logging/logTagSet.cpp line 79:

> 77:   LogDecorations decorations(level, *this, _decorators);
> 78: 
> 79:   for (; it != _output_list.end(); it++) {

The reordering here needs a comment, else someone will be tempted to restore it to the original form.

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

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

From xliu at openjdk.java.net  Wed Jun  9 07:16:15 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 9 Jun 2021 07:16:15 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
Message-ID: <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>

On Wed, 9 Jun 2021 04:41:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> src/hotspot/share/logging/logConfiguration.cpp line 268:
> 
>> 266:   //
>> 267:   // LogDecorator is a set of decorators represented in a uint. sizeof(uint) is not greater than a machine word,
>> 268:   // so store of it is atomic on the mainstream processors. I.e. readers see either its older value or new value.
> 
> This is not necessarily true - the field also has to have correct alignment to ensure atomic accesses. The convention we are adopting is that all racily accessed fields like _decorators should be declared volatile, and accessed using Atomic::load and Atomic::store.

To support machines without unaligned memory access, C++ defines "alignment requirement" for class and struct. 
Not only sizeof(LogDecorators) == sizeof(uint) == 4, C++ can also guarantee that alignof(logDecorators) is 4. 
Therefore, it's impossible that to unaligned access for its field _decorators. 


class LogDecorators {
  uint _decorators;
};


Therefore, I think the current code which use normal assignment is atomic. Of course, using Atomic::store manifests it's an atomic store. I will try to use Atomic::store().

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

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

From rehn at openjdk.java.net  Wed Jun  9 07:25:23 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 9 Jun 2021 07:25:23 GMT
Subject: Integrated: 8266557:
 assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
In-Reply-To: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
References: <sNQCTddqOTCZ6kENm9j3WzUCgyfpGDROZiDHaC-_d3A=.e8c8b2ac-1bff-432a-aa04-52f0bc30d8d6@github.com>
Message-ID: <b81stNguzYjrMQYOXFclBKQBaIQBt1Ju6GjDxgZmh7U=.99c9281a-d1ab-4a8b-b53c-aca7998e9274@github.com>

On Tue, 11 May 2021 11:59:23 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Please consider this change-set which address the issue on hand.
> 
> I identified two problems:
> 
> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
> Fixed by leaving the handshakee being processed in queue until completed.
> And remove looping, since if ever the queue is empty the handshakee may processed.
> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
> 
> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
> 
> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
> Fixed by adding a loadload.
> 
> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
> (real reprod ~1/400 with increased test time)
> If we are updating the poll there should not be an active handshaker.
> The above fixed the issue.
> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
> 
> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
> 
> Passes stressing relevant test on aarch64 and t1-7.
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: 2bfd708e
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2bfd708e9276bd9a6d4cf493e1af3a8e5b8026d2
Stats:     158 lines in 6 files changed: 83 ins; 42 del; 33 mod

8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be

Reviewed-by: pchilanomate, dcubed

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

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

From mgronlun at openjdk.java.net  Wed Jun  9 08:50:19 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Jun 2021 08:50:19 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <Rmrmgookko0CSfZz81x-ooj09mThi7-usVHbTgX2ebA=.5f737e0c-caeb-45ef-9c86-329e107e6dba@github.com>
Message-ID: <eK6pFYY8DXPKrwvDEWht-Vc0omsQhVHgBPOrp4zVsCc=.f0e5e88b-25c0-49b9-b59c-5e1784d47fb4@github.com>

On Mon, 7 Jun 2021 07:01:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   read once
>
> This is a race-condition and will potentially fail just the same way the bug in #4224 did. There needs to be at least Atomic::loads of the the variables, or the compiler could convert the loads into multiple loads.

@stefank @dholmes-ora Are you ok with the suggested fix? The decision to have the impl in the .cpp is to avoid having to include runtime/atomic.hpp in the .inline.hpp file unnecessarily (not deemed performance sensitive). Let me know if you prefer the impl in the .inline.hpp instead.

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

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

From mbaesken at openjdk.java.net  Wed Jun  9 09:17:27 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 9 Jun 2021 09:17:27 GMT
Subject: RFR: JDK-8268377: Windows 32bit build fails after JDK-8268174
Message-ID: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>

Hello, please review this small patch. It contains some build adjustments for compiling on windows 32bit after https://bugs.openjdk.java.net/browse/JDK-8268174 .

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

Commit messages:
 - JDK-8268377

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

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

From jiefu at openjdk.java.net  Wed Jun  9 09:28:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 9 Jun 2021 09:28:12 GMT
Subject: RFR: JDK-8268377: Windows 32bit build fails after JDK-8268174
In-Reply-To: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>
References: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>
Message-ID: <g60SUo0HyZZ08JiF0BqmmFfCJKK4dxsMb4hIz8bTGFQ=.84687d4a-13ad-412a-9b87-ef58663b172a@github.com>

On Wed, 9 Jun 2021 09:09:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small patch. It contains some build adjustments for compiling on windows 32bit after https://bugs.openjdk.java.net/browse/JDK-8268174 .

Looks good to me and trivial IMO.
Thanks.

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

Marked as reviewed by jiefu (Reviewer).

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

From mdoerr at openjdk.java.net  Wed Jun  9 12:29:15 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 9 Jun 2021 12:29:15 GMT
Subject: RFR: JDK-8268377: Windows 32bit build fails after JDK-8268174
In-Reply-To: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>
References: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>
Message-ID: <QPMe44cDoO7K7aEDo1vRd0UtwIOS5uFbFvn8ZOazZXs=.3d80565f-1535-44f5-b4c1-8ed0fc88ac4d@github.com>

On Wed, 9 Jun 2021 09:09:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small patch. It contains some build adjustments for compiling on windows 32bit after https://bugs.openjdk.java.net/browse/JDK-8268174 .

Looks good. Thanks for fixing!

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

Marked as reviewed by mdoerr (Reviewer).

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

From dholmes at openjdk.java.net  Wed Jun  9 13:39:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 13:39:17 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
Message-ID: <yWYXC-K798AY6okpwbJx6pze5PlvdeZzFw7T3l4WZqo=.491667a7-0120-4427-9e62-b3861f264fe5@github.com>

On Mon, 7 Jun 2021 14:15:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   read once

src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 478:

> 476: }
> 477: 
> 478: const HeapWord* ThreadLocalAllocBuffer::start_relaxed() const {

Why do we need the "relaxed" terminology? By default accessors have no memory ordering properties.

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

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

From stefank at openjdk.java.net  Wed Jun  9 13:54:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 9 Jun 2021 13:54:14 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <yWYXC-K798AY6okpwbJx6pze5PlvdeZzFw7T3l4WZqo=.491667a7-0120-4427-9e62-b3861f264fe5@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
 <yWYXC-K798AY6okpwbJx6pze5PlvdeZzFw7T3l4WZqo=.491667a7-0120-4427-9e62-b3861f264fe5@github.com>
Message-ID: <FSXpyBXrnn-Isy-gS9XhUDHWq5PFfiyI5NAo3knkatQ=.ba6cc7a1-d19f-4950-a08d-dd0fdbebaf52@github.com>

On Wed, 9 Jun 2021 13:36:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   read once
>
> src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 478:
> 
>> 476: }
>> 477: 
>> 478: const HeapWord* ThreadLocalAllocBuffer::start_relaxed() const {
> 
> Why do we need the "relaxed" terminology? By default accessors have no memory ordering properties.

I'm not sure what you are asking, but Atomic::load implements the "relaxed" semantics equivalent to using MO_RELAXED in the Access API.

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

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

From mbaesken at openjdk.java.net  Wed Jun  9 14:14:21 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 9 Jun 2021 14:14:21 GMT
Subject: Integrated: JDK-8268377: Windows 32bit build fails after JDK-8268174
In-Reply-To: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>
References: <sJIFnJs8M-M4E49U3M_hHkDpcywDIuWm0TkmsqhZ_cg=.38aba5b2-57ce-4bd1-9c4a-12c1d855a4d2@github.com>
Message-ID: <e9I60HCPE205tMnnBlZbfl-XV1lSgsPxWDjGjSoPY5E=.9fc029d1-a534-4b0b-8fbe-ca63f74af850@github.com>

On Wed, 9 Jun 2021 09:09:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small patch. It contains some build adjustments for compiling on windows 32bit after https://bugs.openjdk.java.net/browse/JDK-8268174 .

This pull request has now been integrated.

Changeset: 43e38a18
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/43e38a18b83a69242d1991f435d23d8799f06fe6
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8268377: Windows 32bit build fails after JDK-8268174

Reviewed-by: jiefu, mdoerr

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

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

From aph at redhat.com  Wed Jun  9 16:45:10 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Jun 2021 17:45:10 +0100
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <f4125026-e3ba-1f73-3571-c843de58d8e7@redhat.com>

On 6/5/21 4:21 PM, Daniel D.Daugherty wrote:
> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.
> 
> -------------
> 
> Commit messages:
>  - 8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4374/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4374&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8268286
>   Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/4374.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/4374/head:pull/4374
> 
> PR: https://git.openjdk.java.net/jdk/pull/4374
> 

What is the actual bug? I just ran this test with ZGC/Linux/AArch64 and it seems to
be fine.

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


From iklam at openjdk.java.net  Wed Jun  9 17:17:12 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Jun 2021 17:17:12 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again
In-Reply-To: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
Message-ID: <-o1FR_6QChxTo2ExNWFYH0Hjb-lrKrWnDcXMI_jjOwo=.9b06d9d6-b98a-4a5f-8292-1b24d4757094@github.com>

On Wed, 9 Jun 2021 16:24:42 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
> 
> Tests: tier1,tier2,tier3,tier4,tier7
> Local tests: jtreg/hotspot/runtime/cds
> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
> 
> Thanks
> Yumin

LGTM. Some small nits.

src/hotspot/share/classfile/systemDictionary.hpp line 84:

> 82: class TableStatistics;
> 83: 
> 84: class SharedClassLoadingMark {

I think it's better to put this class into systemDictionaryShared.hpp

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1054:

> 1052:     if ((SystemDictionary::is_system_class_loader(class_loader()) && ik->is_shared_app_class())  ||
> 1053:         (SystemDictionary::is_platform_class_loader(class_loader()) && ik->is_shared_platform_class())) {
> 1054:       SharedClassLoadingMark slm(THREAD, ik);

`!ik->is_shared_boot_class()` is not needed because lines 1052 and 1053 will check for the proper loader type.

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

Marked as reviewed by iklam (Reviewer).

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

From minqi at openjdk.java.net  Wed Jun  9 17:42:19 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 9 Jun 2021 17:42:19 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again
In-Reply-To: <-o1FR_6QChxTo2ExNWFYH0Hjb-lrKrWnDcXMI_jjOwo=.9b06d9d6-b98a-4a5f-8292-1b24d4757094@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <-o1FR_6QChxTo2ExNWFYH0Hjb-lrKrWnDcXMI_jjOwo=.9b06d9d6-b98a-4a5f-8292-1b24d4757094@github.com>
Message-ID: <g3JEtH2sn4YAqJrryGZad3xkfmdJjUDfB4HynuB6rVk=.ba092e2c-ca02-43a5-b77e-714a7bb967af@github.com>

On Wed, 9 Jun 2021 17:09:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi, Please review
>>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
>> 
>> Tests: tier1,tier2,tier3,tier4,tier7
>> Local tests: jtreg/hotspot/runtime/cds
>> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
>> 
>> Thanks
>> Yumin
>
> src/hotspot/share/classfile/systemDictionary.hpp line 84:
> 
>> 82: class TableStatistics;
>> 83: 
>> 84: class SharedClassLoadingMark {
> 
> I think it's better to put this class into systemDictionaryShared.hpp

The move to systemDictionaryShared.hpp will cause zero build failed. We need a guard for CDS at:
1294     if (k != NULL) {
1295       SharedClassLoadingMark slm(THREAD, k);
1296       k = find_or_define_instance_class(class_name, class_loader, k, CHECK_NULL);
1297     }
That makes the code looks fragmented. Do you agree to keep it not moved?

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

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

From minqi at openjdk.java.net  Wed Jun  9 17:48:14 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 9 Jun 2021 17:48:14 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again
In-Reply-To: <g3JEtH2sn4YAqJrryGZad3xkfmdJjUDfB4HynuB6rVk=.ba092e2c-ca02-43a5-b77e-714a7bb967af@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <-o1FR_6QChxTo2ExNWFYH0Hjb-lrKrWnDcXMI_jjOwo=.9b06d9d6-b98a-4a5f-8292-1b24d4757094@github.com>
 <g3JEtH2sn4YAqJrryGZad3xkfmdJjUDfB4HynuB6rVk=.ba092e2c-ca02-43a5-b77e-714a7bb967af@github.com>
Message-ID: <Txl7CUW45RqOXh9QXgdJIrv5ByAh_C6lkpVMUtBMkJc=.ec734020-167c-4971-b0cf-957f14975b39@github.com>

On Wed, 9 Jun 2021 17:39:33 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.hpp line 84:
>> 
>>> 82: class TableStatistics;
>>> 83: 
>>> 84: class SharedClassLoadingMark {
>> 
>> I think it's better to put this class into systemDictionaryShared.hpp
>
> The move to systemDictionaryShared.hpp will cause zero build failed. We need a guard for CDS at:
> 1294     if (k != NULL) {
> 1295       SharedClassLoadingMark slm(THREAD, k);
> 1296       k = find_or_define_instance_class(class_name, class_loader, k, CHECK_NULL);
> 1297     }
> That makes the code looks fragmented. Do you agree to keep it not moved?

Maybe we should add guard here for shared code --- putting it to systemDictionaryShared.hpp is more reasonable.

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

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

From iignatyev at openjdk.java.net  Wed Jun  9 18:34:31 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 9 Jun 2021 18:34:31 GMT
Subject: RFR: 8268475: execute runtime/InvocationTests w/ -UseVtableBasedCHA
Message-ID: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>

Hi all,

could you please review this small test-only patch?
from JBS:
> execution of runtime/InvocationTests w/ -XX:-UseVtableBasedCHA can be instrumental in finding bugs in the old implementation of CHA.

the patch adds a new test `invocationOldCHATests.java` which is based on `invocationC1Tests.java` but runs the tests w/ `-Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA`.

testing: `invocationOldCHATests.java` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

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

Commit messages:
 - 8268475

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

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

From mseledtsov at openjdk.java.net  Wed Jun  9 18:48:16 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 9 Jun 2021 18:48:16 GMT
Subject: RFR: 8268475: execute runtime/InvocationTests w/
 -UseVtableBasedCHA
In-Reply-To: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
References: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
Message-ID: <6DZuxXoO1QMZ6WE8_oUnJTYF22oIPhvnBnk4HqNBGX4=.2062e16e-d2c9-4f86-a750-3287af210804@github.com>

On Wed, 9 Jun 2021 18:23:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> execution of runtime/InvocationTests w/ -XX:-UseVtableBasedCHA can be instrumental in finding bugs in the old implementation of CHA.
> 
> the patch adds a new test `invocationOldCHATests.java` which is based on `invocationC1Tests.java` but runs the tests w/ `-Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA`.
> 
> testing: `invocationOldCHATests.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Looks good to me. Please fix the copyright note before integration.

test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2021, Oracle and/or its affiliates. All rights reserved.

Since this is a new test, should this be just 2021, no 2019?

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

Marked as reviewed by mseledtsov (Committer).

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

From iignatyev at openjdk.java.net  Wed Jun  9 18:53:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 9 Jun 2021 18:53:13 GMT
Subject: RFR: 8268475: execute runtime/InvocationTests w/
 -UseVtableBasedCHA
In-Reply-To: <6DZuxXoO1QMZ6WE8_oUnJTYF22oIPhvnBnk4HqNBGX4=.2062e16e-d2c9-4f86-a750-3287af210804@github.com>
References: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
 <6DZuxXoO1QMZ6WE8_oUnJTYF22oIPhvnBnk4HqNBGX4=.2062e16e-d2c9-4f86-a750-3287af210804@github.com>
Message-ID: <UL4Ss0moWyOCxr4pN-tiOmqfdC22DY_cVOQ_F3YG9hw=.e3b6357f-e854-4018-bb25-c1d3079dab02@github.com>

On Wed, 9 Jun 2021 18:42:57 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small test-only patch?
>> from JBS:
>>> execution of runtime/InvocationTests w/ -XX:-UseVtableBasedCHA can be instrumental in finding bugs in the old implementation of CHA.
>> 
>> the patch adds a new test `invocationOldCHATests.java` which is based on `invocationC1Tests.java` but runs the tests w/ `-Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA`.
>> 
>> testing: `invocationOldCHATests.java` on `{linux,windows,macosx}-x64`
>> 
>> Thanks,
>> -- Igor
>
> test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Since this is a new test, should this be just 2021, no 2019?

well, this file (and the majority of its code) is based on the file which was originated in 2019, hence I believe it should be 2019.

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

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

From mseledtsov at openjdk.java.net  Wed Jun  9 18:53:15 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 9 Jun 2021 18:53:15 GMT
Subject: RFR: 8268475: execute runtime/InvocationTests w/
 -UseVtableBasedCHA
In-Reply-To: <UL4Ss0moWyOCxr4pN-tiOmqfdC22DY_cVOQ_F3YG9hw=.e3b6357f-e854-4018-bb25-c1d3079dab02@github.com>
References: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
 <6DZuxXoO1QMZ6WE8_oUnJTYF22oIPhvnBnk4HqNBGX4=.2062e16e-d2c9-4f86-a750-3287af210804@github.com>
 <UL4Ss0moWyOCxr4pN-tiOmqfdC22DY_cVOQ_F3YG9hw=.e3b6357f-e854-4018-bb25-c1d3079dab02@github.com>
Message-ID: <5fChkMJZjUr2o0Llje5nDcnuny2DZk815IZuktO4bBM=.b71f1c1f-42b9-4594-a142-48f74c96dba7@github.com>

On Wed, 9 Jun 2021 18:48:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2019, 2021, Oracle and/or its affiliates. All rights reserved.
>> 
>> Since this is a new test, should this be just 2021, no 2019?
>
> well, this file (and the majority of its code) is based on the file which was originated in 2019, hence I believe it should be 2019.

OK. Thanks for clarification.

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

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

From xliu at openjdk.java.net  Wed Jun  9 18:54:13 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 9 Jun 2021 18:54:13 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
Message-ID: <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>

On Wed, 9 Jun 2021 04:48:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> src/hotspot/share/logging/logTagSet.cpp line 79:
> 
>> 77:   LogDecorations decorations(level, *this, _decorators);
>> 78: 
>> 79:   for (; it != _output_list.end(); it++) {
> 
> The reordering here needs a comment, else someone will be tempted to restore it to the original form.

The order does matter. There is a very tricky race condition.  Here is the original order.  


A: LogDecorations decorations(level, *this, _decorators);
> B: LogOutputList::Iterator it = _output_list.iterator(level);
C: for (; it != _output_list.end(); it++) {


The context switch may happen right before stmt B.  Stmt A has been executed and it used the old _decorators. 
However, the global counter hasn't increased yet so `wait_until_no_readers()` doesn't take any effect because the reader counter is zero.  Another thread which is executing `LogConfiguration::configure_output` can change LogOutput::decorators.  If the user selects more decorators than old,  `LogFileStreamOutput::write_decorations`
will print more decorators which are not initialized in `LogDecorations` ctor.

The newly added LogConfigurationTest.reconfigure_decorators_MT unveils this issue. It could happen with both synchronous logging or async logging.  Tier-1 test on github workflow uses 2 cores. it's easy to trigger this problem if Linux preemptive is enabled.

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

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

From minqi at openjdk.java.net  Wed Jun  9 19:04:35 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 9 Jun 2021 19:04:35 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v2]
In-Reply-To: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
Message-ID: <mX9QJMRoXII2pugtF3Ls74ic8weKi9WoQfqUO9p_6cw=.ac5de866-5074-4ec5-a665-5d60afa4f83c@github.com>

> Hi, Please review
>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
> 
> Tests: tier1,tier2,tier3,tier4,tier7
> Local tests: jtreg/hotspot/runtime/cds
> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
> 
> Thanks
> Yumin

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

  Move SharedClassLoadingMark to systemDictionaryShared.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4434/files
  - new: https://git.openjdk.java.net/jdk/pull/4434/files/3ca038ea..4cb6d351

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

  Stats: 37 lines in 4 files changed: 19 ins; 17 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4434/head:pull/4434

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

From ccheung at openjdk.java.net  Wed Jun  9 19:18:18 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 9 Jun 2021 19:18:18 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v2]
In-Reply-To: <mX9QJMRoXII2pugtF3Ls74ic8weKi9WoQfqUO9p_6cw=.ac5de866-5074-4ec5-a665-5d60afa4f83c@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <mX9QJMRoXII2pugtF3Ls74ic8weKi9WoQfqUO9p_6cw=.ac5de866-5074-4ec5-a665-5d60afa4f83c@github.com>
Message-ID: <77KjXcKwKF-OAnVP5_HbjsSyHSguLeOJARiUbxjBAtQ=.5689ba6d-2052-436f-b6fe-46cc3cee8761@github.com>

On Wed, 9 Jun 2021 19:04:35 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
>> 
>> Tests: tier1,tier2,tier3,tier4,tier7
>> Local tests: jtreg/hotspot/runtime/cds
>> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SharedClassLoadingMark to systemDictionaryShared.hpp

Looks good.

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

Marked as reviewed by ccheung (Reviewer).

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

From iklam at openjdk.java.net  Wed Jun  9 19:18:19 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Jun 2021 19:18:19 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v2]
In-Reply-To: <mX9QJMRoXII2pugtF3Ls74ic8weKi9WoQfqUO9p_6cw=.ac5de866-5074-4ec5-a665-5d60afa4f83c@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <mX9QJMRoXII2pugtF3Ls74ic8weKi9WoQfqUO9p_6cw=.ac5de866-5074-4ec5-a665-5d60afa4f83c@github.com>
Message-ID: <c_pTEG2M7W8TDL0tXrjnS1lFXm3tcdJBp138jXXsq_0=.e2d23124-653b-40aa-aef6-fba172bf2927@github.com>

On Wed, 9 Jun 2021 19:04:35 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
>> 
>> Tests: tier1,tier2,tier3,tier4,tier7
>> Local tests: jtreg/hotspot/runtime/cds
>> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SharedClassLoadingMark to systemDictionaryShared.hpp

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

> 1295: #if INCLUDE_CDS
> 1296:       SharedClassLoadingMark slm(THREAD, k);
> 1297: #endif

I think it's cleaner to use the CDS_ONLY macro. This macro is already used elsewhere in this file.


CDS_ONLY(SharedClassLoadingMark slm(THREAD, k));

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

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

From kvn at openjdk.java.net  Wed Jun  9 20:04:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 9 Jun 2021 20:04:20 GMT
Subject: RFR: 8268475: execute runtime/InvocationTests w/
 -UseVtableBasedCHA
In-Reply-To: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
References: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
Message-ID: <zZpwV35owvmn5HodnCnorb8M8BDjizH_0mhd1CKsxvQ=.47627247-d515-4b9d-981b-9aa41cce3ba3@github.com>

On Wed, 9 Jun 2021 18:23:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> execution of runtime/InvocationTests w/ -XX:-UseVtableBasedCHA can be instrumental in finding bugs in the old implementation of CHA.
> 
> the patch adds a new test `invocationOldCHATests.java` which is based on `invocationC1Tests.java` but runs the tests w/ `-Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA`.
> 
> testing: `invocationOldCHATests.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by kvn (Reviewer).

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

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

From iklam at openjdk.java.net  Wed Jun  9 20:56:16 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Jun 2021 20:56:16 GMT
Subject: RFR: 8267556: Enhance class paths check during runtime
In-Reply-To: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
References: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
Message-ID: <320VgyolGuca8FvRkS8YFBMpByaNpSTiPK4zgRwYVx4=.872df311-e28a-4caa-8f7f-a0616b2a46bc@github.com>

On Mon, 7 Jun 2021 23:09:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During CDS dump time, if an entry in the classpath isn't a jar file, the entry will not be recorded in the archive header. However, during runtime, it attempts to compare all the entries in the classpath against the entries from the archive header. The loading of CDS archive would fail if there exists an non-jar entry in the classpath.
> 
> The proposed patch addresses the above issue. It adds a `bool _has_non_jar_in_classpath` to indicate if a non-jar entry has been encountered during dump time in the archive header. This is to minimize the performance impact for the usual cases where there is no non-jar entry in the classpath.
> 
> - [x] mach5 tiers 1 - 4 (including the new test)
> 
> This is targeted for JDK18.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4402

From minqi at openjdk.java.net  Wed Jun  9 21:28:33 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 9 Jun 2021 21:28:33 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v3]
In-Reply-To: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
Message-ID: <ClqeoBbGc8yHkwV0KpdRzzYfdVYIffHbjpnP5sSCeq4=.2dc1da9c-b24a-4e3c-a3f9-1d904038b9db@github.com>

> Hi, Please review
>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
> 
> Tests: tier1,tier2,tier3,tier4,tier7
> Local tests: jtreg/hotspot/runtime/cds
> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Use CDS_ONLY for one line to replace INCLUDE_CDS

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4434/files
  - new: https://git.openjdk.java.net/jdk/pull/4434/files/4cb6d351..951c0fae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4434&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4434&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4434/head:pull/4434

PR: https://git.openjdk.java.net/jdk/pull/4434

From iklam at openjdk.java.net  Wed Jun  9 21:28:34 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Jun 2021 21:28:34 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v3]
In-Reply-To: <ClqeoBbGc8yHkwV0KpdRzzYfdVYIffHbjpnP5sSCeq4=.2dc1da9c-b24a-4e3c-a3f9-1d904038b9db@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <ClqeoBbGc8yHkwV0KpdRzzYfdVYIffHbjpnP5sSCeq4=.2dc1da9c-b24a-4e3c-a3f9-1d904038b9db@github.com>
Message-ID: <rziumy5QQlXaeRoEBnbjJ8gExWQSIWTLL38fsoqeE38=.8d4104e6-a384-4dbc-85f1-6a0639d145db@github.com>

On Wed, 9 Jun 2021 21:25:13 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
>> 
>> Tests: tier1,tier2,tier3,tier4,tier7
>> Local tests: jtreg/hotspot/runtime/cds
>> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use CDS_ONLY for one line to replace INCLUDE_CDS

Latest version LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4434

From minqi at openjdk.java.net  Wed Jun  9 21:38:15 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 9 Jun 2021 21:38:15 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v3]
In-Reply-To: <rziumy5QQlXaeRoEBnbjJ8gExWQSIWTLL38fsoqeE38=.8d4104e6-a384-4dbc-85f1-6a0639d145db@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <ClqeoBbGc8yHkwV0KpdRzzYfdVYIffHbjpnP5sSCeq4=.2dc1da9c-b24a-4e3c-a3f9-1d904038b9db@github.com>
 <rziumy5QQlXaeRoEBnbjJ8gExWQSIWTLL38fsoqeE38=.8d4104e6-a384-4dbc-85f1-6a0639d145db@github.com>
Message-ID: <0nSfJ4wLUGSDR5bA-2kGh4GyaKgRLihvgdq4nIfxETI=.048c40e9-a4a1-4983-b40d-e96d46b5c39b@github.com>

On Wed, 9 Jun 2021 21:24:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use CDS_ONLY for one line to replace INCLUDE_CDS
>
> Latest version LGTM

@iklam @calvinccheung 
Thanks for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4434

From minqi at openjdk.java.net  Wed Jun  9 21:38:16 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 9 Jun 2021 21:38:16 GMT
Subject: Integrated: 8267954: Shared classes that failed to load should not be
 loaded again
In-Reply-To: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
Message-ID: <-JRscM5TCQn0ZiZIwjesbeG5YZsHyEES80Vp-rzPHR4=.9b9c1bb8-4220-4890-a4e4-7a64b9aa80c2@github.com>

On Wed, 9 Jun 2021 16:24:42 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
> 
> Tests: tier1,tier2,tier3,tier4,tier7
> Local tests: jtreg/hotspot/runtime/cds
> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: 7ff6e7b2
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ff6e7b2b1be088c37f50756b6822be01b4c657d
Stats:     72 lines in 7 files changed: 36 ins; 21 del; 15 mod

8267954: Shared classes that failed to load should not be loaded again

Reviewed-by: iklam, ccheung

-------------

PR: https://git.openjdk.java.net/jdk/pull/4434

From darcy at openjdk.java.net  Thu Jun 10 00:47:35 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Jun 2021 00:47:35 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v8]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <wrM28DZF1nzm10xXJAOzWT2k_-0pw7paJDqSbRd75JI=.b3035f35-93a2-4802-9dd5-787830123dfb@github.com>

> 8267630: Start of release updates for JDK 18

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Update symbols for JDK 17 b25.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/b41f3f8e...ae4d6cce

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4175/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=07
  Stats: 5334 lines in 63 files changed: 5292 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

PR: https://git.openjdk.java.net/jdk/pull/4175

From yyang at openjdk.java.net  Thu Jun 10 02:16:25 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 10 Jun 2021 02:16:25 GMT
Subject: RFR: 8268425: Show integer nid of OSThread instead of hex format one
Message-ID: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>

>From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.

Jstack Before:

"ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable

"ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable

"ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable

Jstack After:
"G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable

"G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable

"G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable

Top:
   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
 99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

-------------

Commit messages:
 - print tid directly

Changes: https://git.openjdk.java.net/jdk/pull/4449/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268425
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From iignatyev at openjdk.java.net  Thu Jun 10 03:22:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 03:22:20 GMT
Subject: Integrated: 8268475: execute runtime/InvocationTests w/
 -UseVtableBasedCHA
In-Reply-To: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
References: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
Message-ID: <GzCSTaM-ssIEJ2jnmWATF1jgwoDKXocuQ5WLAjKuL14=.c74ab0ae-c2e8-4577-9d61-b7ba83f77680@github.com>

On Wed, 9 Jun 2021 18:23:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> execution of runtime/InvocationTests w/ -XX:-UseVtableBasedCHA can be instrumental in finding bugs in the old implementation of CHA.
> 
> the patch adds a new test `invocationOldCHATests.java` which is based on `invocationC1Tests.java` but runs the tests w/ `-Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA`.
> 
> testing: `invocationOldCHATests.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 2623b0bf
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2623b0bf3954df43504ca531cb2ab33b2363929a
Stats:     7 lines in 1 file changed: 0 ins; 1 del; 6 mod

8268475: execute runtime/InvocationTests w/ -UseVtableBasedCHA

Reviewed-by: mseledtsov, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4438

From iignatyev at openjdk.java.net  Thu Jun 10 03:22:18 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 03:22:18 GMT
Subject: RFR: 8268475: execute runtime/InvocationTests w/
 -UseVtableBasedCHA
In-Reply-To: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
References: <gEhBCXbSeL2c_FKNphBrnkIIjgNWs0Px5Cxp6s2P4iA=.cc88727e-16ff-49cb-82d5-05eec9f8e8e4@github.com>
Message-ID: <VY_0X4sIgh40U5Cu0HoOYZt5yK8tvwI-rGjEp3pcd2Y=.758ae890-a0ce-4b0f-85ef-4da4636ba4ed@github.com>

On Wed, 9 Jun 2021 18:23:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> execution of runtime/InvocationTests w/ -XX:-UseVtableBasedCHA can be instrumental in finding bugs in the old implementation of CHA.
> 
> the patch adds a new test `invocationOldCHATests.java` which is based on `invocationC1Tests.java` but runs the tests w/ `-Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA`.
> 
> testing: `invocationOldCHATests.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Misha, Vladimir, thank you for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4438

From dholmes at openjdk.java.net  Thu Jun 10 04:18:20 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 04:18:20 GMT
Subject: RFR: 8267954: Shared classes that failed to load should not be
 loaded again [v3]
In-Reply-To: <ClqeoBbGc8yHkwV0KpdRzzYfdVYIffHbjpnP5sSCeq4=.2dc1da9c-b24a-4e3c-a3f9-1d904038b9db@github.com>
References: <sx-TpCGyMd3i0rbp8Mt-1F91b0t5Qwx1GDeFM1HTkGE=.edaa4b27-71e9-431c-a7cb-5e9fb9d2c57c@github.com>
 <ClqeoBbGc8yHkwV0KpdRzzYfdVYIffHbjpnP5sSCeq4=.2dc1da9c-b24a-4e3c-a3f9-1d904038b9db@github.com>
Message-ID: <EWP3ogx604vAAegDjxFHhrJYm5jexRL1TxCoOd7hgY8=.dd8e729f-59c5-48ee-83b2-d509232ef25e@github.com>

On Wed, 9 Jun 2021 21:28:33 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>>   Shared classes should not be loaded again at failed loading from CDS. In the failed case, restore_unshareable_info failed due to some reason (OOM), but the class already polluted and failed to be loaded again.
>>   Using the unused bit in _misc_flags indicates shared loading status to prevent it from being loaded again.
>> 
>> Tests: tier1,tier2,tier3,tier4,tier7
>> Local tests: jtreg/hotspot/runtime/cds
>> TestDynamicDumpAtOom.java (which failed in tier7) with variant allocation sizes (used to reproduce the failure) passed.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use CDS_ONLY for one line to replace INCLUDE_CDS

src/hotspot/share/oops/instanceKlass.hpp line 364:

> 362:   }
> 363: 
> 364:   void clear_shared_loading_failed() {

This seems unused. And I would not expect loading to "unfail" so can't see why this bit once set would ever be cleared.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4434

From david.holmes at oracle.com  Thu Jun 10 04:33:52 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Jun 2021 14:33:52 +1000
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <FSXpyBXrnn-Isy-gS9XhUDHWq5PFfiyI5NAo3knkatQ=.ba6cc7a1-d19f-4950-a08d-dd0fdbebaf52@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
 <yWYXC-K798AY6okpwbJx6pze5PlvdeZzFw7T3l4WZqo=.491667a7-0120-4427-9e62-b3861f264fe5@github.com>
 <FSXpyBXrnn-Isy-gS9XhUDHWq5PFfiyI5NAo3knkatQ=.ba6cc7a1-d19f-4950-a08d-dd0fdbebaf52@github.com>
Message-ID: <ee48730d-9253-4286-d905-9c508346c8ab@oracle.com>

On 9/06/2021 11:54 pm, Stefan Karlsson wrote:
> On Wed, 9 Jun 2021 13:36:31 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    read once
>>
>> src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 478:
>>
>>> 476: }
>>> 477:
>>> 478: const HeapWord* ThreadLocalAllocBuffer::start_relaxed() const {
>>
>> Why do we need the "relaxed" terminology? By default accessors have no memory ordering properties.
> 
> I'm not sure what you are asking, but Atomic::load implements the "relaxed" semantics equivalent to using MO_RELAXED in the Access API.

I see this terminology is used in some of the GC code but I was not 
aware of its existence. I also see nothing in atomic.hpp that states 
that Atomic::load/store implement memory_order_relaxed ?? Is the 
difference between unordered and relaxed what you get from applying 
volatile to the variable being accessed? So unordered from a h/w 
perspective but with some constraints on the compiler to maintain 
program order?

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4363
> 

From dholmes at openjdk.java.net  Thu Jun 10 05:00:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 05:00:14 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
 <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>
Message-ID: <VLpLtLoQWcu_7C04Rk3JZXEIcoh0k5IwzVzccxRgRdk=.e88175f0-58b6-4e72-a3fb-767b33a896d0@github.com>

On Wed, 9 Jun 2021 18:51:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logTagSet.cpp line 79:
>> 
>>> 77:   LogDecorations decorations(level, *this, _decorators);
>>> 78: 
>>> 79:   for (; it != _output_list.end(); it++) {
>> 
>> The reordering here needs a comment, else someone will be tempted to restore it to the original form.
>
> The order does matter. There is a very tricky race condition.  Here is the original order.  
> 
> 
> A: LogDecorations decorations(level, *this, _decorators);
>> B: LogOutputList::Iterator it = _output_list.iterator(level);
> C: for (; it != _output_list.end(); it++) {
> 
> 
> The context switch may happen right before stmt B.  Stmt A has been executed and it used the old _decorators. 
> However, the global counter hasn't increased yet so `wait_until_no_readers()` doesn't take any effect because the reader counter is zero.  Another thread which is executing `LogConfiguration::configure_output` can change LogOutput::decorators.  If the user selects more decorators than old,  `LogFileStreamOutput::write_decorations`
> will print more decorators which are not initialized in `LogDecorations` ctor.
> 
> The newly added LogConfigurationTest.reconfigure_decorators_MT unveils this issue. It could happen with both synchronous logging or async logging.  Tier-1 test on github workflow uses 2 cores. it's easy to trigger this problem if Linux preemptive is enabled.

I understand there is a race. I'm asking you to add a comment explaining there is a race so that someone is not tempted to reorder these statements again. That said it seems to me that we also require a `loadload` barrier between these (which would pair with the storestore barrier in `LogConfiguration::configure_output`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From darcy at openjdk.java.net  Thu Jun 10 05:16:36 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Jun 2021 05:16:36 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v9]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <VlMpWIf4JjoD18O7Bd5JCGgQJt0sB8wy7Z3zhQ3_jig=.cbcb22c0-c0ec-4d42-97c2-95902aab388f@github.com>

> 8267630: Start of release updates for JDK 18

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Update symbols for JDK 17 b25.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/2623b0bf...794f3173

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4175/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=08
  Stats: 5334 lines in 63 files changed: 5292 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

PR: https://git.openjdk.java.net/jdk/pull/4175

From darcy at openjdk.java.net  Thu Jun 10 06:53:34 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Jun 2021 06:53:34 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v10]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <NbFBayRcQ8C6Anp9cnJsxVYt83n1UbKLG7dK-zmwcSE=.fd80b82c-db06-4939-9857-a45f3f74948a@github.com>

> 8267630: Start of release updates for JDK 18

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Update copyright year.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Update symbols for JDK 17 b25.
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/dd1cbadc...aaf47c1f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4175/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=09
  Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

PR: https://git.openjdk.java.net/jdk/pull/4175

From stefank at openjdk.java.net  Thu Jun 10 06:55:15 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 10 Jun 2021 06:55:15 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <ee48730d-9253-4286-d905-9c508346c8ab@oracle.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <ee48730d-9253-4286-d905-9c508346c8ab@oracle.com>
Message-ID: <-bwk7jVRuepzEBqMaGafsO1fo9pG5Zul7Qy4t7xZJlw=.df907758-1420-4c38-b0ae-6def6a2cea61@github.com>

On Thu, 10 Jun 2021 04:35:50 GMT, David Holmes <david.holmes at oracle.com> wrote:

> > I'm not sure what you are asking, but Atomic::load implements the "relaxed" semantics equivalent to using MO_RELAXED in the Access API.
> 
> I see this terminology is used in some of the GC code but I was not
> aware of its existence.

This is not a GC-specific terminology, but a C++11 terminology:
https://en.cppreference.com/w/cpp/atomic/memory_order

> I also see nothing in atomic.hpp that states
> that Atomic::load/store implement memory_order_relaxed ?? 

In atomic.hpp there are references to relaxed at the top of the file:

enum atomic_memory_order {
  // The modes that align with C++11 are intended to
  // follow the same semantics.
  memory_order_relaxed = 0,
  memory_order_acquire = 2,
  memory_order_release = 3,
  memory_order_acq_rel = 4,
  // Strong two-way memory barrier.
  memory_order_conservative = 8
};


But you are right, nothing here helps the reader understand that Atomic::load implies relaxed. This needs to be better documented.

> Is the
> difference between unordered and relaxed what you get from applying
> volatile to the variable being accessed? So unordered from a h/w
> perspective but with some constraints on the compiler to maintain
> program order?

I talked to @fisk about this yesterday, and IIUC relaxed access are not supposed to be reordered by the HW, but volatile access could be.

> 
> Thanks,
> David
> -----

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From xliu at openjdk.java.net  Thu Jun 10 07:09:13 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 10 Jun 2021 07:09:13 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
Message-ID: <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>

On Wed, 9 Jun 2021 07:13:10 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logConfiguration.cpp line 268:
>> 
>>> 266:   //
>>> 267:   // LogDecorator is a set of decorators represented in a uint. sizeof(uint) is not greater than a machine word,
>>> 268:   // so store of it is atomic on the mainstream processors. I.e. readers see either its older value or new value.
>> 
>> This is not necessarily true - the field also has to have correct alignment to ensure atomic accesses. The convention we are adopting is that all racily accessed fields like _decorators should be declared volatile, and accessed using Atomic::load and Atomic::store.
>
> To support machines without unaligned memory access, C++ defines "alignment requirement" for class and struct. 
> Not only sizeof(LogDecorators) == sizeof(uint) == 4, C++ can also guarantee that alignof(logDecorators) is 4. 
> Therefore, it's impossible that to unaligned access for its field _decorators. 
> 
> 
> class LogDecorators {
>   uint _decorators;
> };
> 
> 
> Therefore, I think the current code which use normal assignment is atomic. Of course, using Atomic::store manifests it's an atomic store. I will try to use Atomic::store().

Could you take a look at my argument? IMHO, C++ can guarantee the following code is atomic. 
Alignment shouldn't an issue. 


void LogOutput::set_decorators(const LogDecorators& decorators) {
    _decorators = decorators;
}


I manage to support the following code. The generated code is exactly same, but it needs some tricks of c++ meta-programming.  Is it worthy?  if you still insist we should use Atomic::store, how about I create a separate JBS issue and submit a patch?  My concern is that Atomic::load/store makes current code messy. 


void LogOutput::set_decorators(const LogDecorators& decorators) {
  Atomic::store(&_decorators, decorators);
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Thu Jun 10 07:19:10 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 10 Jun 2021 07:19:10 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <VLpLtLoQWcu_7C04Rk3JZXEIcoh0k5IwzVzccxRgRdk=.e88175f0-58b6-4e72-a3fb-767b33a896d0@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
 <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>
 <VLpLtLoQWcu_7C04Rk3JZXEIcoh0k5IwzVzccxRgRdk=.e88175f0-58b6-4e72-a3fb-767b33a896d0@github.com>
Message-ID: <AF_lWIIpinRYRu31FLLZHMy4M7HdKV-kaoVFHS8Xhwk=.f555e324-28cf-4058-9c08-2340ee61c692@github.com>

On Thu, 10 Jun 2021 04:57:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The order does matter. There is a very tricky race condition.  Here is the original order.  
>> 
>> 
>> A: LogDecorations decorations(level, *this, _decorators);
>>> B: LogOutputList::Iterator it = _output_list.iterator(level);
>> C: for (; it != _output_list.end(); it++) {
>> 
>> 
>> The context switch may happen right before stmt B.  Stmt A has been executed and it used the old _decorators. 
>> However, the global counter hasn't increased yet so `wait_until_no_readers()` doesn't take any effect because the reader counter is zero.  Another thread which is executing `LogConfiguration::configure_output` can change LogOutput::decorators.  If the user selects more decorators than old,  `LogFileStreamOutput::write_decorations`
>> will print more decorators which are not initialized in `LogDecorations` ctor.
>> 
>> The newly added LogConfigurationTest.reconfigure_decorators_MT unveils this issue. It could happen with both synchronous logging or async logging.  Tier-1 test on github workflow uses 2 cores. it's easy to trigger this problem if Linux preemptive is enabled.
>
> I understand there is a race. I'm asking you to add a comment explaining there is a race so that someone is not tempted to reorder these statements again. That said it seems to me that we also require a `loadload` barrier between these (which would pair with the storestore barrier in `LogConfiguration::configure_output`).

I see. I would like to convince reviewers first. I will add some comments here. 

I don't think loadload barrier is necessary.  volatile in c/c++ is a little bit different from Java. we can't fully apply JSR-133 here. Yes, we do need to make sure Atomic::add() happens before load of decorators. This is done by the implied memory barrier of `Atomic::add`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From david.holmes at oracle.com  Thu Jun 10 07:58:55 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Jun 2021 17:58:55 +1000
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow
In-Reply-To: <-bwk7jVRuepzEBqMaGafsO1fo9pG5Zul7Qy4t7xZJlw=.df907758-1420-4c38-b0ae-6def6a2cea61@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <ee48730d-9253-4286-d905-9c508346c8ab@oracle.com>
 <-bwk7jVRuepzEBqMaGafsO1fo9pG5Zul7Qy4t7xZJlw=.df907758-1420-4c38-b0ae-6def6a2cea61@github.com>
Message-ID: <f72b6252-3475-3ecb-d43a-ffafc037e716@oracle.com>

On 10/06/2021 4:55 pm, Stefan Karlsson wrote:
> On Thu, 10 Jun 2021 04:35:50 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>>> I'm not sure what you are asking, but Atomic::load implements the "relaxed" semantics equivalent to using MO_RELAXED in the Access API.
>>
>> I see this terminology is used in some of the GC code but I was not
>> aware of its existence.
> 
> This is not a GC-specific terminology, but a C++11 terminology:
> https://en.cppreference.com/w/cpp/atomic/memory_order

I meant in the context of the hotspot sources and its use in method names.

>> I also see nothing in atomic.hpp that states
>> that Atomic::load/store implement memory_order_relaxed ??
> 
> In atomic.hpp there are references to relaxed at the top of the file:
> 
> enum atomic_memory_order {
>    // The modes that align with C++11 are intended to
>    // follow the same semantics.
>    memory_order_relaxed = 0,
>    memory_order_acquire = 2,
>    memory_order_release = 3,
>    memory_order_acq_rel = 4,
>    // Strong two-way memory barrier.
>    memory_order_conservative = 8
> };
> 
> 
> But you are right, nothing here helps the reader understand that Atomic::load implies relaxed. This needs to be better documented.

What am I missing - I can't see any memory barrier related instructions 
  associated with basic Atomic::load and store. Granted store needs 
nothing on TSO and on non-TSO the barrier may be implicit in whatever 
platform intrinsic is used; but loads would also need explicit barriers 
to prevent reordering ??

David
-----

>> Is the
>> difference between unordered and relaxed what you get from applying
>> volatile to the variable being accessed? So unordered from a h/w
>> perspective but with some constraints on the compiler to maintain
>> program order?
> 
> I talked to @fisk about this yesterday, and IIUC relaxed access are not supposed to be reordered by the HW, but volatile access could be.
> 
>>
>> Thanks,
>> David
>> -----
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4363
> 

From xliu at openjdk.java.net  Thu Jun 10 08:04:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 10 Jun 2021 08:04:37 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <ZPiav3ti_pmBc6jLuCl7wRnJIU_nqWgrALUNLcVCjoY=.658bbf09-4ba1-420c-a77b-fe4131732a22@github.com>

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Add comments in LogTagSet::log().

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4408/files
  - new: https://git.openjdk.java.net/jdk/pull/4408/files/9aa4aac5..6e51b96e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=00-01

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408

PR: https://git.openjdk.java.net/jdk/pull/4408

From stefank at openjdk.java.net  Thu Jun 10 09:19:20 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 10 Jun 2021 09:19:20 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
Message-ID: <QXgKtxU9skUGLf9C8ZEGg6P8Xyvyq_aiBjVedamxxrA=.95e7d24d-91ef-43f6-9eb8-5eb1bfd92311@github.com>

On Mon, 7 Jun 2021 14:15:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   read once

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-jfr-dev](mailto:hotspot-jfr-dev at mail.openjdk.java.net):_
> 
> On 10/06/2021 4:55 pm, Stefan Karlsson wrote:
> 
> > On Thu, 10 Jun 2021 04:35:50 GMT, David Holmes <david.holmes at oracle.com> wrote:
> > > > I'm not sure what you are asking, but Atomic::load implements the "relaxed" semantics equivalent to using MO_RELAXED in the Access API.
> > > 
> > > 
> > > I see this terminology is used in some of the GC code but I was not
> > > aware of its existence.
> > 
> > 
> > This is not a GC-specific terminology, but a C++11 terminology:
> > https://en.cppreference.com/w/cpp/atomic/memory_order
> 
> I meant in the context of the hotspot sources and its use in method names.

I guess the other parts of HotSpot needs to get on board with this terminology now that we have gone to C++11.

> 
> > > I also see nothing in atomic.hpp that states
> > > that Atomic::load/store implement memory_order_relaxed ??
> > 
> > 
> > In atomic.hpp there are references to relaxed at the top of the file:
> > enum atomic_memory_order {
> > // The modes that align with C++11 are intended to
> > // follow the same semantics.
> > memory_order_relaxed = 0,
> > memory_order_acquire = 2,
> > memory_order_release = 3,
> > memory_order_acq_rel = 4,
> > // Strong two-way memory barrier.
> > memory_order_conservative = 8
> > };
> > But you are right, nothing here helps the reader understand that Atomic::load implies relaxed. This needs to be better documented.
> 
> What am I missing - I can't see any memory barrier related instructions
> associated with basic Atomic::load and store. Granted store needs
> nothing on TSO and on non-TSO the barrier may be implicit in whatever
> platform intrinsic is used; but loads would also need explicit barriers
> to prevent reordering ??

AFAIK, the code was written prior to C++11 and nothing else is needed on our currently supported platforms. Though I've heard stories about some platforms that probably would have to fix this. I've also heard @fisk argue that we should replace the Atomic::load implementation with the compiler's version of relaxed atomic loads.

> 
> David
> -----

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From stuefe at openjdk.java.net  Thu Jun 10 10:00:27 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Jun 2021 10:00:27 GMT
Subject: RFR: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
Message-ID: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>

For JDK-8185734: "[Windows] Structured Exception Catcher missing around gtest execution", I specified that --gtest_catch_exceptions=0 should be specified to leave signal handling to the VM. This was needed to prevent the gtest runner from catching the stack-based SEH exceptions bubbling up from the tested VM, and leave them to our upstairs gtest runner wrapper to catch.

However, there is a typo:

--gtest_catch_exceptions=0test_result.xml


Unless I am mistaken, it did not seem to have impeded Windows gtests (in particular, the tests in runtime/test_safefetch.cpp). So I think this was a benign error.

-------------

Commit messages:
 - remove typo

Changes: https://git.openjdk.java.net/jdk/pull/4025/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4025&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267138
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4025.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4025/head:pull/4025

PR: https://git.openjdk.java.net/jdk/pull/4025

From iignatyev at openjdk.java.net  Thu Jun 10 10:33:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 10:33:21 GMT
Subject: RFR: 8268542: serviceability/logging/TestFullNames.java tests only
 1st test case
Message-ID: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>

Hi all,

could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
from JBS:
> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.

the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.

testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - 8268542

Changes: https://git.openjdk.java.net/jdk/pull/4461/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4461&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268542
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4461.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4461/head:pull/4461

PR: https://git.openjdk.java.net/jdk/pull/4461

From iignatyev at openjdk.java.net  Thu Jun 10 10:52:26 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 10:52:26 GMT
Subject: RFR: 8268543: some runtime/verifier tests should be run in driver mode
Message-ID: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>

Hi all,

could you please review the patch that switches the execution mode in a few `runtime/verifier` tests to `driver`?

testing: `runtime/verifier` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright year
 - 8268543

Changes: https://git.openjdk.java.net/jdk/pull/4462/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4462&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268543
  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4462.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4462/head:pull/4462

PR: https://git.openjdk.java.net/jdk/pull/4462

From iignatyev at openjdk.java.net  Thu Jun 10 11:02:25 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 11:02:25 GMT
Subject: RFR: 8268544: some runtime/sealedClasses tests should be run in
 driver mode
Message-ID: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>

Hi all,

could you please review this small and trivial patch that changes the execution mode to `driver` in two `runtime/sealedClasses` tests?

testing:  `runtime/sealedClasses` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - 8268544

Changes: https://git.openjdk.java.net/jdk/pull/4463/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4463&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268544
  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4463/head:pull/4463

PR: https://git.openjdk.java.net/jdk/pull/4463

From iignatyev at openjdk.java.net  Thu Jun 10 12:33:14 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 12:33:14 GMT
Subject: RFR: 8268543: some runtime/verifier tests should be run in driver
 mode
In-Reply-To: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>
References: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>
Message-ID: <rXZwz5Pw6sCUOpCdDDPsglcGgF62V53CA3rP6XQvEF4=.ee5d1d4e-b4b9-44ae-8214-edd7f9ae0030@github.com>

On Thu, 10 Jun 2021 10:45:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch that switches the execution mode in a few `runtime/verifier` tests to `driver`?
> 
> testing: `runtime/verifier` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thanks, Harold!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4462

From iignatyev at openjdk.java.net  Thu Jun 10 12:33:14 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 12:33:14 GMT
Subject: Integrated: 8268543: some runtime/verifier tests should be run in
 driver mode
In-Reply-To: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>
References: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>
Message-ID: <KeMve8yYtPdabv82JGB9itZcIr9TsiEKBG-rCBkbPxo=.48d8f76d-4d6d-4c68-8069-846deee08e7b@github.com>

On Thu, 10 Jun 2021 10:45:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch that switches the execution mode in a few `runtime/verifier` tests to `driver`?
> 
> testing: `runtime/verifier` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 6b6ff536
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b6ff5360a2813354735ef9eda6729c853696702
Stats:     10 lines in 3 files changed: 0 ins; 0 del; 10 mod

8268543: some runtime/verifier tests should be run in driver mode

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/jdk/pull/4462

From hseigel at openjdk.java.net  Thu Jun 10 12:33:14 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 10 Jun 2021 12:33:14 GMT
Subject: RFR: 8268543: some runtime/verifier tests should be run in driver
 mode
In-Reply-To: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>
References: <gLxd3KVMlOEIeklzoL1X1mOlNTaLwm0gSLg6p8-Tyko=.22b2065c-edd1-4fc5-8f27-1b6818ef795f@github.com>
Message-ID: <29dfNtuWvwOUsJOTWcH1Nk0ISPraI41izNG5_LiM3eI=.a53c953c-14e4-4ff4-ab7c-428b0555ebdb@github.com>

On Thu, 10 Jun 2021 10:45:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch that switches the execution mode in a few `runtime/verifier` tests to `driver`?
> 
> testing: `runtime/verifier` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Changes look good and trivial.  Thanks for fixing this.
Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4462

From dholmes at openjdk.java.net  Thu Jun 10 12:52:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 12:52:16 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <AF_lWIIpinRYRu31FLLZHMy4M7HdKV-kaoVFHS8Xhwk=.f555e324-28cf-4058-9c08-2340ee61c692@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
 <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>
 <VLpLtLoQWcu_7C04Rk3JZXEIcoh0k5IwzVzccxRgRdk=.e88175f0-58b6-4e72-a3fb-767b33a896d0@github.com>
 <AF_lWIIpinRYRu31FLLZHMy4M7HdKV-kaoVFHS8Xhwk=.f555e324-28cf-4058-9c08-2340ee61c692@github.com>
Message-ID: <KSObw2sFy03s6d90rcmXsWlkvYx7FNjP_lO-xf5Rx9A=.a6643a65-e424-47a6-9325-b38558675228@github.com>

On Thu, 10 Jun 2021 07:16:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I understand there is a race. I'm asking you to add a comment explaining there is a race so that someone is not tempted to reorder these statements again. That said it seems to me that we also require a `loadload` barrier between these (which would pair with the storestore barrier in `LogConfiguration::configure_output`).
>
> I see. I would like to convince reviewers first. I will add some comments here. 
> 
> I don't think loadload barrier is necessary.  volatile in c/c++ is a little bit different from Java. we can't fully apply JSR-133 here. Yes, we do need to make sure Atomic::add() happens before load of decorators. This is done by the implied memory barrier of `Atomic::add`.

I have no idea why you mention volatile and jsr-133 here.

If there is an Atomic::add inside there then okay the necessary barrier may be in place. But it is not at all apparent there is an Atomic operation inside there, so given the order is important the comment needs to explain why an explicit barrier is not needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From hseigel at openjdk.java.net  Thu Jun 10 13:01:22 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 10 Jun 2021 13:01:22 GMT
Subject: RFR: 8268544: some runtime/sealedClasses tests should be run in
 driver mode
In-Reply-To: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>
References: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>
Message-ID: <FdaptSusWKr6eFSTwuXhlKnQsZrWL9YckhUXNYk0fj0=.e850085f-ddf2-4eda-aad0-dd366a4791f8@github.com>

On Thu, 10 Jun 2021 10:54:23 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that changes the execution mode to `driver` in two `runtime/sealedClasses` tests?
> 
> testing:  `runtime/sealedClasses` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

LGTM and trivial.  Thanks for fixing this.
Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4463

From dholmes at openjdk.java.net  Thu Jun 10 13:02:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 13:02:21 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
 <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
 <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>
Message-ID: <BLhkmfT1RAFxMhRhBd2XUVnDR7KCsuAcrSc0lYb5jPk=.f889fdff-a601-4df9-841c-aaa236be056d@github.com>

On Thu, 10 Jun 2021 12:53:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Could you take a look at my argument? IMHO, C++ can guarantee the following code is atomic. 
>> Alignment shouldn't an issue. 
>> 
>> 
>> void LogOutput::set_decorators(const LogDecorators& decorators) {
>>     _decorators = decorators;
>> }
>> 
>> 
>> I manage to support the following code. The generated code is exactly same, but it needs some tricks of c++ meta-programming.  Is it worthy?  if you still insist we should use Atomic::store, how about I create a separate JBS issue and submit a patch?  My concern is that Atomic::load/store makes current code messy. 
>> 
>> 
>> void LogOutput::set_decorators(const LogDecorators& decorators) {
>>   Atomic::store(&_decorators, decorators);
>> }
>
> C++ makes no guarantees about atomicity unless using C++ atomic operations. Yes they probably are atomic but we don't rely on "probably". If a variable is being accessed lock-free and can take part in data-race then please just use Atomic::load and store for simple accesses (assuming they are correct in the context of how the variable can be used concurrently).

Sorry I just realized what you are saying here. This is a LogDecorator type not a primitive type so the notion of atomic load/store doesn't make sense. The comments about it being a bitfield threw me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From dholmes at openjdk.java.net  Thu Jun 10 13:02:20 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 13:02:20 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
 <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
Message-ID: <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>

On Thu, 10 Jun 2021 07:06:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> To support machines without unaligned memory access, C++ defines "alignment requirement" for class and struct. 
>> Not only sizeof(LogDecorators) == sizeof(uint) == 4, C++ can also guarantee that alignof(logDecorators) is 4. 
>> Therefore, it's impossible that to unaligned access for its field _decorators. 
>> 
>> 
>> class LogDecorators {
>>   uint _decorators;
>> };
>> 
>> 
>> Therefore, I think the current code which use normal assignment is atomic. Of course, using Atomic::store manifests it's an atomic store. I will try to use Atomic::store().
>
> Could you take a look at my argument? IMHO, C++ can guarantee the following code is atomic. 
> Alignment shouldn't an issue. 
> 
> 
> void LogOutput::set_decorators(const LogDecorators& decorators) {
>     _decorators = decorators;
> }
> 
> 
> I manage to support the following code. The generated code is exactly same, but it needs some tricks of c++ meta-programming.  Is it worthy?  if you still insist we should use Atomic::store, how about I create a separate JBS issue and submit a patch?  My concern is that Atomic::load/store makes current code messy. 
> 
> 
> void LogOutput::set_decorators(const LogDecorators& decorators) {
>   Atomic::store(&_decorators, decorators);
> }

C++ makes no guarantees about atomicity unless using C++ atomic operations. Yes they probably are atomic but we don't rely on "probably". If a variable is being accessed lock-free and can take part in data-race then please just use Atomic::load and store for simple accesses (assuming they are correct in the context of how the variable can be used concurrently).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From dholmes at openjdk.java.net  Thu Jun 10 13:02:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 13:02:21 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <BLhkmfT1RAFxMhRhBd2XUVnDR7KCsuAcrSc0lYb5jPk=.f889fdff-a601-4df9-841c-aaa236be056d@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
 <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
 <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>
 <BLhkmfT1RAFxMhRhBd2XUVnDR7KCsuAcrSc0lYb5jPk=.f889fdff-a601-4df9-841c-aaa236be056d@github.com>
Message-ID: <Q7EXm8STkVH2oE8Lf9Jvno7-TqtRxYosJVlDsJplQEc=.c5d10bff-a963-4ef6-8a93-7c6b67bae57b@github.com>

On Thu, 10 Jun 2021 12:56:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> C++ makes no guarantees about atomicity unless using C++ atomic operations. Yes they probably are atomic but we don't rely on "probably". If a variable is being accessed lock-free and can take part in data-race then please just use Atomic::load and store for simple accesses (assuming they are correct in the context of how the variable can be used concurrently).
>
> Sorry I just realized what you are saying here. This is a LogDecorator type not a primitive type so the notion of atomic load/store doesn't make sense. The comments about it being a bitfield threw me.

It is the load/store of `uint _decorators;` that needs to be atomic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From dcubed at openjdk.java.net  Thu Jun 10 13:04:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 13:04:40 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v4]
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <uE7hTwBGfRWx8jYnZMJqBYYKM9oC4BRXj9Ej75lDrIY=.146cda56-92d9-4bff-a140-bc510b69256b@github.com>

> The Thread-SMR project added counter based tests for various APIs.
> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
> 
> Time based tests are more appropriate for stress kits so I'm
> updating the counter based tests to be time based instead.
> 
> Two of the updated tests have shaken out failures that are tracked by:
> 
>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
> 
>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
> 
> These updated tests are tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-5].

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  dholmes CR - fix indent on usage() calls.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4237/files
  - new: https://git.openjdk.java.net/jdk/pull/4237/files/5c2633dd..2daef5aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=02-03

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4237.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4237/head:pull/4237

PR: https://git.openjdk.java.net/jdk/pull/4237

From dcubed at openjdk.java.net  Thu Jun 10 13:04:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 13:04:41 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <9XZwKF1ewPtfgMAoVxuetYqllxp_hJmjhoQRnTR_dxQ=.db6b1c69-7753-4b38-96b8-22d1250940e3@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>
 <9XZwKF1ewPtfgMAoVxuetYqllxp_hJmjhoQRnTR_dxQ=.db6b1c69-7753-4b38-96b8-22d1250940e3@github.com>
Message-ID: <39sopRkDtSzPKiMzI3kFh-mGIHrdGtojPLx8C8gzhNY=.9f5a9160-fbb6-416a-8aa0-c1e19be9a0f1@github.com>

On Wed, 9 Jun 2021 01:51:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ProblemList vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java until 8264605 is fixed and vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java until 8266593 is fixed.
>
> Hi Dan,
> 
> This all seems okay. Sorry it took so long to get to it.
> 
> Note: All the usage() calls are indented incorrectly.
> 
> Thanks,
> David

@dholmes-ora - Thanks for the review! I fixed the indent on the usage() calls.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4237

From iignatyev at openjdk.java.net  Thu Jun 10 13:07:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 13:07:19 GMT
Subject: RFR: 8268544: some runtime/sealedClasses tests should be run in
 driver mode
In-Reply-To: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>
References: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>
Message-ID: <ff4I58uKwuUsXy8ZWQZz8QgfvQUVecBkH7M5NLAIfJ4=.bd30f767-3e44-4b56-916c-d10264c5cceb@github.com>

On Thu, 10 Jun 2021 10:54:23 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that changes the execution mode to `driver` in two `runtime/sealedClasses` tests?
> 
> testing:  `runtime/sealedClasses` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thank you, Harold.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4463

From iignatyev at openjdk.java.net  Thu Jun 10 13:07:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 13:07:20 GMT
Subject: Integrated: 8268544: some runtime/sealedClasses tests should be run
 in driver mode
In-Reply-To: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>
References: <OBRVgokCR_Y-sDo9II48wH02LuAvWX-th1rpOGEZgzI=.64bfadc9-be62-45fc-9345-f0e10bf79623@github.com>
Message-ID: <erRXmJkcFYXgJXT8hnZ3-TUviKMqBMM1zLStgq1JYqs=.b9b123c2-70e0-4379-9d5b-5ae36b7f36df@github.com>

On Thu, 10 Jun 2021 10:54:23 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that changes the execution mode to `driver` in two `runtime/sealedClasses` tests?
> 
> testing:  `runtime/sealedClasses` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 6c552a7b
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6c552a7b42e73174343280d46bd72d730c42b5c5
Stats:     6 lines in 2 files changed: 2 ins; 0 del; 4 mod

8268544: some runtime/sealedClasses tests should be run in driver mode

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/jdk/pull/4463

From stefank at openjdk.java.net  Thu Jun 10 13:07:21 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 10 Jun 2021 13:07:21 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
Message-ID: <RwCtWWoT06eAkHBsTaPCNnsxfLf2Y2d8Jz4EqOPgDgE=.3ae540eb-6c04-4193-af21-cff001be8ed9@github.com>

On Mon, 7 Jun 2021 14:15:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   read once

Kim has been looking through the standards w.r.t. atomic and read-read coherence and has some insights. Could be worth reading:
https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-June/052745.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From dcubed at openjdk.java.net  Thu Jun 10 13:12:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 13:12:20 GMT
Subject: Integrated: 8266130: convert Thread-SMR stress tests from counter
 based to time based
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <KnUp14t4H6pX70ZWbauUeetC7oeE5KSunfIp_vy3MEc=.1deb7cf3-652b-4873-8728-1a4fef2c04a7@github.com>

On Fri, 28 May 2021 00:13:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> The Thread-SMR project added counter based tests for various APIs.
> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
> 
> Time based tests are more appropriate for stress kits so I'm
> updating the counter based tests to be time based instead.
> 
> Two of the updated tests have shaken out failures that are tracked by:
> 
>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
> 
>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
> 
> These updated tests are tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-5].

This pull request has now been integrated.

Changeset: f677163b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f677163b8aad13781be51839f27742c2213896d1
Stats:     983 lines in 21 files changed: 398 ins; 291 del; 294 mod

8266130: convert Thread-SMR stress tests from counter based to time based

Reviewed-by: cjplummer, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4237

From darcy at openjdk.java.net  Thu Jun 10 14:42:24 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Jun 2021 14:42:24 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v11]
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <twBFh74ldOcA0VPZyX8SNlGbyO9nQzVvLPhu1FGc5HQ=.970dde84-80e4-4b44-93ee-09a4f7b7123a@github.com>

> 8267630: Start of release updates for JDK 18

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into 8267630
 - Update copyright year.
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - Merge branch 'master' into 8267630
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4175/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=10
  Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175

PR: https://git.openjdk.java.net/jdk/pull/4175

From sspitsyn at openjdk.java.net  Thu Jun 10 14:46:58 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 14:46:58 GMT
Subject: RFR: 8268542: serviceability/logging/TestFullNames.java tests
 only 1st test case
In-Reply-To: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
References: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
Message-ID: <JumBRr9VSPH6L1QlfefQSasRGWw2i31Rmn_kH-yxboo=.bc809670-08d4-4c86-91b9-e7880f1ecc35@github.com>

On Thu, 10 Jun 2021 10:26:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
> from JBS:
>> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.
> 
> the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.
> 
> testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4461

From iignatyev at openjdk.java.net  Thu Jun 10 14:46:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 14:46:59 GMT
Subject: Integrated: 8268542: serviceability/logging/TestFullNames.java tests
 only 1st test case
In-Reply-To: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
References: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
Message-ID: <bk0yzoS6M7TqFRncVfx1SVsX89MxsouifgOTRqS-yRg=.be7bbe58-7a6d-41b3-897e-2abef462704b@github.com>

On Thu, 10 Jun 2021 10:26:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
> from JBS:
>> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.
> 
> the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.
> 
> testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 74007890
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/74007890bb9a3fa3a65683a3f480e399f2b1a0b6
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268542: serviceability/logging/TestFullNames.java tests only 1st test case

Reviewed-by: sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4461

From iignatyev at openjdk.java.net  Thu Jun 10 14:46:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 14:46:59 GMT
Subject: RFR: 8268542: serviceability/logging/TestFullNames.java tests
 only 1st test case
In-Reply-To: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
References: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
Message-ID: <Q70rU2KzaGcbeBqXmp0fxoC4lTUmR3ut4sWhQy0pKZQ=.10124010-315e-49c5-957a-5622cab91b66@github.com>

On Thu, 10 Jun 2021 10:26:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
> from JBS:
>> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.
> 
> the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.
> 
> testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thanks, Serguei!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4461

From iris at openjdk.java.net  Thu Jun 10 14:49:59 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 10 Jun 2021 14:49:59 GMT
Subject: RFR: 8267630: Start of release updates for JDK 18 [v11]
In-Reply-To: <twBFh74ldOcA0VPZyX8SNlGbyO9nQzVvLPhu1FGc5HQ=.970dde84-80e4-4b44-93ee-09a4f7b7123a@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
 <twBFh74ldOcA0VPZyX8SNlGbyO9nQzVvLPhu1FGc5HQ=.970dde84-80e4-4b44-93ee-09a4f7b7123a@github.com>
Message-ID: <d4wwyaipTqQVOmtb6JDI_oUdFOmWmWnFDqivV8S8z-A=.63bbd2b2-a5d0-4cef-bca4-65eb80666f68@github.com>

On Thu, 10 Jun 2021 14:42:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8267630: Start of release updates for JDK 18
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into 8267630
>  - Update copyright year.
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4175

From ccheung at openjdk.java.net  Thu Jun 10 16:22:41 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 10 Jun 2021 16:22:41 GMT
Subject: RFR: 8267556: Enhance class paths check during runtime
In-Reply-To: <320VgyolGuca8FvRkS8YFBMpByaNpSTiPK4zgRwYVx4=.872df311-e28a-4caa-8f7f-a0616b2a46bc@github.com>
References: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
 <320VgyolGuca8FvRkS8YFBMpByaNpSTiPK4zgRwYVx4=.872df311-e28a-4caa-8f7f-a0616b2a46bc@github.com>
Message-ID: <ts-PdfGzNOp4vjMjTzU0bV8Y4QvnypYmzLWEkN3C3vM=.911b4b20-c4b1-45b4-aeef-614fcceada1e@github.com>

On Wed, 9 Jun 2021 20:53:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> During CDS dump time, if an entry in the classpath isn't a jar file, the entry will not be recorded in the archive header. However, during runtime, it attempts to compare all the entries in the classpath against the entries from the archive header. The loading of CDS archive would fail if there exists an non-jar entry in the classpath.
>> 
>> The proposed patch addresses the above issue. It adds a `bool _has_non_jar_in_classpath` to indicate if a non-jar entry has been encountered during dump time in the archive header. This is to minimize the performance impact for the usual cases where there is no non-jar entry in the classpath.
>> 
>> - [x] mach5 tiers 1 - 4 (including the new test)
>> 
>> This is targeted for JDK18.
>
> LGTM

@iklam, @yminqi Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4402

From darcy at openjdk.java.net  Thu Jun 10 16:28:01 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Jun 2021 16:28:01 GMT
Subject: Integrated: 8267630: Start of release updates for JDK 18
In-Reply-To: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
References: <f5035Fmu8J1vjvVIkbFXsgg26_6UqCjtYUkAbXVDNn4=.12f10326-270f-42f6-9846-af1e284e46f3@github.com>
Message-ID: <AWqrnojaf4dnuOQGBwGVBWSYuADPj8b5KYQu9UvW8Ro=.81065010-6565-4d44-a0b7-dddd9a55553b@github.com>

On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8267630: Start of release updates for JDK 18

This pull request has now been integrated.

Changeset: b018c450
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b018c450e5e4737ccd08ed505fd06cee16c42648
Stats:     5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod

8267630: Start of release updates for JDK 18
8267632: Add source 18 and target 18 to javac
8267631: Add SourceVersion.RELEASE_18

Reviewed-by: iris, erikj, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4175

From ccheung at openjdk.java.net  Thu Jun 10 16:35:25 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 10 Jun 2021 16:35:25 GMT
Subject: RFR: 8268470: CDS dynamic dump asserts with JFR RecordingStream
Message-ID: <ZOnfqc19NSMMNNhb6PL7C1APoxJhLtvMtGVFtjAclHU=.e467d853-a6b7-4113-947a-95b3c01866e5@github.com>

During JFR startup, it redefines some of the builtin classes like java/lang/Throwable. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.

To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.

- [x] mach5 tier1, tier2 (including the new test)

-------------

Commit messages:
 - fix trailing whitespace
 - 8268470: CDS dynamic dump asserts with JFR RecordingStream

Changes: https://git.openjdk.java.net/jdk/pull/4467/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4467&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268470
  Stats: 193 lines in 4 files changed: 192 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4467/head:pull/4467

PR: https://git.openjdk.java.net/jdk/pull/4467

From dcubed at openjdk.java.net  Thu Jun 10 17:06:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 17:06:59 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <TkqpsyvpwXIwnmpS3wgGhjPxJNp2NW98fENawOLBrqU=.47a263cd-3e5c-4f7b-ba0c-24ac07357eb5@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

This PR is for https://bugs.openjdk.java.net/browse/JDK-8268286 which is a
subtask of https://bugs.openjdk.java.net/browse/JDK-8268283. So the bug
is described by:

    JDK-8268283 serviceability/sa/TestJmapCore.java failed with zgc on linux-aarch64 after JDK-8266957

Hopefully that answers your question.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4374

From iklam at openjdk.java.net  Thu Jun 10 17:19:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 10 Jun 2021 17:19:54 GMT
Subject: RFR: 8268470: CDS dynamic dump asserts with JFR RecordingStream
In-Reply-To: <ZOnfqc19NSMMNNhb6PL7C1APoxJhLtvMtGVFtjAclHU=.e467d853-a6b7-4113-947a-95b3c01866e5@github.com>
References: <ZOnfqc19NSMMNNhb6PL7C1APoxJhLtvMtGVFtjAclHU=.e467d853-a6b7-4113-947a-95b3c01866e5@github.com>
Message-ID: <a7960XVQ8Qmb6z0pfVf-so22r45XAcC1ZhgAojC-WqY=.8c1a8ac1-8987-42c9-9c4f-0d6b59738095@github.com>

On Thu, 10 Jun 2021 16:15:50 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During JFR startup, it redefines some of the builtin classes like java/lang/Throwable. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
> 
> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
> 
> - [x] mach5 tier1, tier2 (including the new test)

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4467

From ccheung at openjdk.java.net  Thu Jun 10 17:47:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 10 Jun 2021 17:47:58 GMT
Subject: Withdrawn: 8268470: CDS dynamic dump asserts with JFR RecordingStream
In-Reply-To: <ZOnfqc19NSMMNNhb6PL7C1APoxJhLtvMtGVFtjAclHU=.e467d853-a6b7-4113-947a-95b3c01866e5@github.com>
References: <ZOnfqc19NSMMNNhb6PL7C1APoxJhLtvMtGVFtjAclHU=.e467d853-a6b7-4113-947a-95b3c01866e5@github.com>
Message-ID: <Atm77UmeelB2FniEeNcyIMGytcbud48P8k1fquhzaEU=.103ee8b1-f5b3-45e1-82e5-ef475d889f0b@github.com>

On Thu, 10 Jun 2021 16:15:50 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During JFR startup, it redefines some of the builtin classes like java/lang/Throwable. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
> 
> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
> 
> - [x] mach5 tier1, tier2 (including the new test)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4467

From ccheung at openjdk.java.net  Thu Jun 10 17:47:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 10 Jun 2021 17:47:58 GMT
Subject: RFR: 8268470: CDS dynamic dump asserts with JFR RecordingStream
In-Reply-To: <a7960XVQ8Qmb6z0pfVf-so22r45XAcC1ZhgAojC-WqY=.8c1a8ac1-8987-42c9-9c4f-0d6b59738095@github.com>
References: <ZOnfqc19NSMMNNhb6PL7C1APoxJhLtvMtGVFtjAclHU=.e467d853-a6b7-4113-947a-95b3c01866e5@github.com>
 <a7960XVQ8Qmb6z0pfVf-so22r45XAcC1ZhgAojC-WqY=.8c1a8ac1-8987-42c9-9c4f-0d6b59738095@github.com>
Message-ID: <v-wqrVFKqt7Z50O__kHgU0FdnV5KVC2_FsLcxkV_J9E=.5611e460-20e9-4f19-814b-c4d822c66693@github.com>

On Thu, 10 Jun 2021 17:16:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> During JFR startup, it redefines some of the builtin classes like java/lang/Throwable. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
>> 
>> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
>> 
>> - [x] mach5 tier1, tier2 (including the new test)
>
> LGTM

@iklam Thanks for your review.
I'll withdraw the PR and rebase it on jdk17 since it is targeted for 17.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4467

From cjplummer at openjdk.java.net  Thu Jun 10 17:48:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 17:48:56 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <cDN4dVSUCkFPfQbuKpxZg4xYoD1zdGVnGdX9mxEj6zA=.fe85c7c5-168e-41cd-97e5-c07a879916f9@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

@theRealAph Also, it seems to fail about 25% of the time, so not surprising if you didn't see it fail unless you ran it at least a few times.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4374

From ccheung at openjdk.java.net  Thu Jun 10 19:02:02 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 10 Jun 2021 19:02:02 GMT
Subject: [jdk17] RFR: 8268470: CDS dynamic dump asserts with JFR
 RecordingStream
Message-ID: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>

During JFR startup, it redefines some of the builtin classes like `java/lang/Throwable`. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.

To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.

- [x] mach5 tier1, tier2 (including the new test) (in progress)

-------------

Commit messages:
 - 8268470: CDS dynamic dump asserts with JFR RecordingStream

Changes: https://git.openjdk.java.net/jdk17/pull/9/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=9&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268470
  Stats: 170 lines in 4 files changed: 169 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk17/pull/9

From iignatyev at openjdk.java.net  Thu Jun 10 19:08:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 19:08:12 GMT
Subject: RFR: 8268565: runtime/records/RedefineRecord.java should be run in
 driver mode
Message-ID: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>

Hi all,

could you please review this small and trivial patch that changes the execution mode to `driver` in `runtime/records/RedefineRecord.java` test?

testing: `runtime/records` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - 8268565

Changes: https://git.openjdk.java.net/jdk/pull/4468/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4468&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268565
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4468.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4468/head:pull/4468

PR: https://git.openjdk.java.net/jdk/pull/4468

From xliu at openjdk.java.net  Thu Jun 10 19:16:01 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 10 Jun 2021 19:16:01 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <Q7EXm8STkVH2oE8Lf9Jvno7-TqtRxYosJVlDsJplQEc=.c5d10bff-a963-4ef6-8a93-7c6b67bae57b@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
 <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
 <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>
 <BLhkmfT1RAFxMhRhBd2XUVnDR7KCsuAcrSc0lYb5jPk=.f889fdff-a601-4df9-841c-aaa236be056d@github.com>
 <Q7EXm8STkVH2oE8Lf9Jvno7-TqtRxYosJVlDsJplQEc=.c5d10bff-a963-4ef6-8a93-7c6b67bae57b@github.com>
Message-ID: <SRMnYsgn-UDwVaEM-TDK2vIZn5MCK2iYQ2TtbFiaZwc=.f5515459-4e96-44e0-afc6-111f67c39a66@github.com>

On Thu, 10 Jun 2021 12:59:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry I just realized what you are saying here. This is a LogDecorator type not a primitive type so the notion of atomic load/store doesn't make sense. The comments about it being a bitfield threw me.
>
> It is the load/store of `uint _decorators;` that needs to be atomic.

I can't overload copy constructor and assignment operator using Atomic because there are many places we don't need atomic operation at all. Of course, I can provide two member functions atomic_load/store for `LogDecorators`.  TBH, I feel I am uglifying code.  Actually I did it, the generated code is exactly same. that's why I am reluctant to use them.

Yes, the atomicity isn't provided by C++. It is provided by both c++ and underneath processors. As long as load/store are aligned and the ALU is 32-bit or wider,  store like c42 is atomic.


0000000000000c40 <LogOutput::set_decorators(LogDecorators const&)>:
     c40:       8b 06                   mov    (%rsi),%eax
     c42:       89 47 20                mov    %eax,0x20(%rdi)
     c45:       c3                      retq


A RCU algorithm never be straightforward. That's why I try to write comments here.  It's not me who introduce this code. I just try to explain how it works. 

How about this? Could you submit this patch to the internal test infra and see if it can pass tier1~tier7? if it can't, we refactor this code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Thu Jun 10 19:20:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 10 Jun 2021 19:20:54 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <KSObw2sFy03s6d90rcmXsWlkvYx7FNjP_lO-xf5Rx9A=.a6643a65-e424-47a6-9325-b38558675228@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
 <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>
 <VLpLtLoQWcu_7C04Rk3JZXEIcoh0k5IwzVzccxRgRdk=.e88175f0-58b6-4e72-a3fb-767b33a896d0@github.com>
 <AF_lWIIpinRYRu31FLLZHMy4M7HdKV-kaoVFHS8Xhwk=.f555e324-28cf-4058-9c08-2340ee61c692@github.com>
 <KSObw2sFy03s6d90rcmXsWlkvYx7FNjP_lO-xf5Rx9A=.a6643a65-e424-47a6-9325-b38558675228@github.com>
Message-ID: <WEjqpbJLcd7x2h3ajnk3b4I-0vd9Z_z5Bn_5CB2jL14=.e3634bc6-5ac7-496d-b2f5-c15d50fa5112@github.com>

On Thu, 10 Jun 2021 12:49:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I see. I would like to convince reviewers first. I will add some comments here. 
>> 
>> I don't think loadload barrier is necessary.  volatile in c/c++ is a little bit different from Java. we can't fully apply JSR-133 here. Yes, we do need to make sure Atomic::add() happens before load of decorators. This is done by the implied memory barrier of `Atomic::add`.
>
> I have no idea why you mention volatile and jsr-133 here.
> 
> If there is an Atomic::add inside there then okay the necessary barrier may be in place. But it is not at all apparent there is an Atomic operation inside there, so given the order is important the comment needs to explain why an explicit barrier is not needed.

The following code uses `Atomic::add`. Actually, there's a hidden 3rd argument. it's a default parameter and I highlight it.  It is the conservative memory order emits a full memory barrier. I double-check the implementations on  x86/aarch64 and powerpc.


jint LogOutputList::increase_readers() {
  jint result = Atomic::add(&_active_readers, 1, /*memory_order_conservative*/);
  assert(_active_readers > 0, "Ensure we have consistent state");
  return result;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From ccheung at openjdk.java.net  Thu Jun 10 19:53:59 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 10 Jun 2021 19:53:59 GMT
Subject: Integrated: 8267556: Enhance class paths check during runtime
In-Reply-To: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
References: <o_YPTwAugS391kHd_70KyaEyUvr40X0DrKS6YiR0jno=.5c7b2d2e-b80d-4cf5-ad63-eb31169e266f@github.com>
Message-ID: <MzMuc6YQFgjImQTU1uid3bb0c4oeX03di9aky_V60ag=.3d2be074-53f1-4841-b879-42cbe2bbd97a@github.com>

On Mon, 7 Jun 2021 23:09:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During CDS dump time, if an entry in the classpath isn't a jar file, the entry will not be recorded in the archive header. However, during runtime, it attempts to compare all the entries in the classpath against the entries from the archive header. The loading of CDS archive would fail if there exists an non-jar entry in the classpath.
> 
> The proposed patch addresses the above issue. It adds a `bool _has_non_jar_in_classpath` to indicate if a non-jar entry has been encountered during dump time in the archive header. This is to minimize the performance impact for the usual cases where there is no non-jar entry in the classpath.
> 
> - [x] mach5 tiers 1 - 4 (including the new test)
> 
> This is targeted for JDK18.

This pull request has now been integrated.

Changeset: 4fd2a149
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fd2a149977b05eb6e4b28d147ab9c043a7934ec
Stats:     101 lines in 7 files changed: 95 ins; 1 del; 5 mod

8267556: Enhance class paths check during runtime

Reviewed-by: minqi, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/4402

From hseigel at openjdk.java.net  Thu Jun 10 19:57:52 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 10 Jun 2021 19:57:52 GMT
Subject: RFR: 8268565: runtime/records/RedefineRecord.java should be run
 in driver mode
In-Reply-To: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>
References: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>
Message-ID: <Dh99WX3JmxNoz-mJScURaUzhdTGm_EgAXAVKNVm8ujg=.00cabebc-7cce-466a-a1fc-7e22941b56e5@github.com>

On Thu, 10 Jun 2021 18:30:13 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that changes the execution mode to `driver` in `runtime/records/RedefineRecord.java` test?
> 
> testing: `runtime/records` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Looks good and trivial.
Thanks, Harodl

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4468

From minqi at openjdk.java.net  Thu Jun 10 20:17:10 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 10 Jun 2021 20:17:10 GMT
Subject: [jdk17] RFR: 8268470: CDS dynamic dump asserts with JFR
 RecordingStream
In-Reply-To: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
References: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
Message-ID: <xFl4M8lywE32JNnj05HdEK5kJCP7WyG0psPZ51zGmfY=.42e1eadc-777f-4bcb-b209-fd604ffaa66a@github.com>

On Thu, 10 Jun 2021 18:53:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During JFR startup, it redefines some of the builtin classes like `java/lang/Throwable`. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
> 
> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
> 
> - [x] mach5 tier1, tier2 (including the new test) (in progress)

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/9

From dcubed at openjdk.java.net  Thu Jun 10 23:12:12 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 23:12:12 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
Message-ID: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>

A trivial fix to ProblemList tests failing due to UseBiasedLocking going away

-------------

Commit messages:
 - 8268574: ProblemList tests failing due to UseBiasedLocking going away

Changes: https://git.openjdk.java.net/jdk/pull/4469/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4469&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268574
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4469/head:pull/4469

PR: https://git.openjdk.java.net/jdk/pull/4469

From cjplummer at openjdk.java.net  Thu Jun 10 23:12:12 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 23:12:12 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
In-Reply-To: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
References: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
Message-ID: <C5ebZOvYB0K-ZPyN-7QZkZjA___eXf5wLDbels1_qHo=.63d8e2d2-71a6-417f-afa3-41b7b2058153@github.com>

On Thu, 10 Jun 2021 22:59:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tests failing due to UseBiasedLocking going away

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4469

From dcubed at openjdk.java.net  Thu Jun 10 23:12:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 23:12:13 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
In-Reply-To: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
References: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
Message-ID: <KcVlmv_9F_49363-vyTPcMhlD8gNgM5jKdtVX3ujxrg=.25981c11-3430-40b0-a3b9-d1d6383161d6@github.com>

On Thu, 10 Jun 2021 22:59:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tests failing due to UseBiasedLocking going away

This pull request has now been integrated.

Changeset: 2e900da5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e900da5f70105c153500908c693b2601fa30477
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8268574: ProblemList tests failing due to UseBiasedLocking going away

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/4469

From dcubed at openjdk.java.net  Thu Jun 10 23:12:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 23:12:13 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
In-Reply-To: <C5ebZOvYB0K-ZPyN-7QZkZjA___eXf5wLDbels1_qHo=.63d8e2d2-71a6-417f-afa3-41b7b2058153@github.com>
References: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
 <C5ebZOvYB0K-ZPyN-7QZkZjA___eXf5wLDbels1_qHo=.63d8e2d2-71a6-417f-afa3-41b7b2058153@github.com>
Message-ID: <Rye1FjuORu87GCLXOYs1ne1rbDqIdM_QL2hO7FY0OSI=.af8a1922-6537-469b-8fa4-dc57d8adab4a@github.com>

On Thu, 10 Jun 2021 23:06:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A trivial fix to ProblemList tests failing due to UseBiasedLocking going away
>
> Marked as reviewed by cjplummer (Reviewer).

@plummercj - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4469

From dholmes at openjdk.java.net  Thu Jun 10 23:24:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 23:24:09 GMT
Subject: RFR: 8257038: Remove expired flags in JDK 18
Message-ID: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>

Simple start of release update:
 - remove 4 expired flags
 - move the now obsoleted flags to the obsoleted flag section
 - update the dummy obsoleted flag

None of the expired flags were documented so no updated needed to any docs in that regard.

Thanks,
David

-------------

Commit messages:
 - 8257038: Remove expired flags in JDK 18

Changes: https://git.openjdk.java.net/jdk/pull/4470/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4470&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257038
  Stats: 17 lines in 1 file changed: 5 ins; 9 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4470/head:pull/4470

PR: https://git.openjdk.java.net/jdk/pull/4470

From kbarrett at openjdk.java.net  Fri Jun 11 01:32:54 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 11 Jun 2021 01:32:54 GMT
Subject: RFR: 8257038: Remove expired flags in JDK 18
In-Reply-To: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
References: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
Message-ID: <DNTVKN3m7OD2uz-FuABCJORf60RDCfPYW6XwGJuEml8=.3fca8b2a-f6cc-4643-b75f-96edd30589f0@github.com>

On Thu, 10 Jun 2021 23:15:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple start of release update:
>  - remove 4 expired flags
>  - move the now obsoleted flags to the obsoleted flag section
>  - update the dummy obsoleted flag
> 
> None of the expired flags were documented so no updated needed to any docs in that regard.
> 
> Thanks,
> David

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4470

From david.holmes at oracle.com  Fri Jun 11 01:36:40 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Jun 2021 11:36:40 +1000
Subject: RFR: 8257038: Remove expired flags in JDK 18
In-Reply-To: <DNTVKN3m7OD2uz-FuABCJORf60RDCfPYW6XwGJuEml8=.3fca8b2a-f6cc-4643-b75f-96edd30589f0@github.com>
References: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
 <DNTVKN3m7OD2uz-FuABCJORf60RDCfPYW6XwGJuEml8=.3fca8b2a-f6cc-4643-b75f-96edd30589f0@github.com>
Message-ID: <4a8bfbf4-76e6-b14d-eaa5-b503a6d894a0@oracle.com>

On 11/06/2021 11:32 am, Kim Barrett wrote:
> On Thu, 10 Jun 2021 23:15:36 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Simple start of release update:
>>   - remove 4 expired flags
>>   - move the now obsoleted flags to the obsoleted flag section
>>   - update the dummy obsoleted flag
>>
>> None of the expired flags were documented so no updated needed to any docs in that regard.
>>
>> Thanks,
>> David
> 
> Looks good.

Thanks Kim!

David
-----

> -------------
> 
> Marked as reviewed by kbarrett (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4470
> 

From ccheung at openjdk.java.net  Fri Jun 11 01:56:53 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Jun 2021 01:56:53 GMT
Subject: RFR: 8257038: Remove expired flags in JDK 18
In-Reply-To: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
References: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
Message-ID: <F3gUCR2eaK5pSPQ-dKTffUvghxsi6jTMUE18df_lynQ=.64fdb618-7e67-481b-9634-1cd220378c6d@github.com>

On Thu, 10 Jun 2021 23:15:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple start of release update:
>  - remove 4 expired flags
>  - move the now obsoleted flags to the obsoleted flag section
>  - update the dummy obsoleted flag
> 
> None of the expired flags were documented so no updated needed to any docs in that regard.
> 
> Thanks,
> David

Looks good.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4470

From iignatyev at openjdk.java.net  Fri Jun 11 02:48:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 02:48:54 GMT
Subject: RFR: 8268565: runtime/records/RedefineRecord.java should be run
 in driver mode
In-Reply-To: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>
References: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>
Message-ID: <WqQ4kWJu_t_MiucPt15yATbK365ImNeS9lKAJjalLX8=.f84565c2-9179-4f2c-8ea0-57a2a3a04a85@github.com>

On Thu, 10 Jun 2021 18:30:13 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that changes the execution mode to `driver` in `runtime/records/RedefineRecord.java` test?
> 
> testing: `runtime/records` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thank you, Harold!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4468

From iignatyev at openjdk.java.net  Fri Jun 11 02:48:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 02:48:55 GMT
Subject: Integrated: 8268565: runtime/records/RedefineRecord.java should be
 run in driver mode
In-Reply-To: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>
References: <RWRBIIiYInlRU-J4Diisn2nIOm6_ArlwOKmTE6erFjc=.ea23db8f-8d32-4648-87d2-76fce89585ec@github.com>
Message-ID: <SKm56xnH62fREKDulcQfWinG2si2IpKomBAnE2BCJ8A=.a665d3b9-0f13-4e5d-91ea-6621d0c712ae@github.com>

On Thu, 10 Jun 2021 18:30:13 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that changes the execution mode to `driver` in `runtime/records/RedefineRecord.java` test?
> 
> testing: `runtime/records` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 94d0b0f9
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94d0b0f9810bd1a8da06ec267a1c7589d6cb756b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8268565: runtime/records/RedefineRecord.java should be run in driver mode

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/jdk/pull/4468

From iignatyev at openjdk.java.net  Fri Jun 11 03:17:11 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 03:17:11 GMT
Subject: [jdk17] Integrated: 8268565: runtime/records/RedefineRecord.java
 should be run in driver mode
In-Reply-To: <W6_k1K91DNVOcGRfMb5Fe0zR5Pn7G5MkS7MK-dH51DM=.68cd0e98-77a6-4a62-8e8d-aa0e94c33cb7@github.com>
References: <W6_k1K91DNVOcGRfMb5Fe0zR5Pn7G5MkS7MK-dH51DM=.68cd0e98-77a6-4a62-8e8d-aa0e94c33cb7@github.com>
Message-ID: <Cik8YcsHVvhkgLXG5b8bumCQaoVd9Z-PzC_h86UwvDE=.8fd14081-c822-406f-b2e4-5d47a22991d7@github.com>

On Fri, 11 Jun 2021 03:06:23 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Backport 8268565 to jdk17.

This pull request has now been integrated.

Changeset: bd9c2fa7
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/bd9c2fa73b61d2461fc44b6056437aee294c9082
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8268565: runtime/records/RedefineRecord.java should be run in driver mode

Backport-of: 94d0b0f9810bd1a8da06ec267a1c7589d6cb756b

-------------

PR: https://git.openjdk.java.net/jdk17/pull/14

From iignatyev at openjdk.java.net  Fri Jun 11 03:17:11 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 03:17:11 GMT
Subject: [jdk17] Integrated: 8268565: runtime/records/RedefineRecord.java
 should be run in driver mode
Message-ID: <W6_k1K91DNVOcGRfMb5Fe0zR5Pn7G5MkS7MK-dH51DM=.68cd0e98-77a6-4a62-8e8d-aa0e94c33cb7@github.com>

Backport 8268565 to jdk17.

-------------

Commit messages:
 - 8268565

Changes: https://git.openjdk.java.net/jdk17/pull/14/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=14&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268565
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/14.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/14/head:pull/14

PR: https://git.openjdk.java.net/jdk17/pull/14

From iignatyev at openjdk.java.net  Fri Jun 11 03:37:16 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 03:37:16 GMT
Subject: [jdk17] RFR: 8268580:
 runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver
 mode
Message-ID: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>

Hi all,

could you please review this small and trivial patch that updates `TestLargePagesFlags.java` test to use `driver` mode?

testing: `runtime/memory/LargePages/`

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright year
 - 8268580

Changes: https://git.openjdk.java.net/jdk17/pull/15/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=15&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268580
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/15/head:pull/15

PR: https://git.openjdk.java.net/jdk17/pull/15

From dholmes at openjdk.java.net  Fri Jun 11 04:17:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 04:17:49 GMT
Subject: RFR: 8257038: Remove expired flags in JDK 18
In-Reply-To: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
References: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
Message-ID: <kMOmDUXuvoJKSW3qkUK_LnQJM_XFnJKPojVaV6uEqRc=.2643cf2f-81f2-4392-a475-abf70635113a@github.com>

On Thu, 10 Jun 2021 23:15:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple start of release update:
>  - remove 4 expired flags
>  - move the now obsoleted flags to the obsoleted flag section
>  - update the dummy obsoleted flag
> 
> None of the expired flags were documented so no updated needed to any docs in that regard.
> 
> Thanks,
> David

Thanks Calvin!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4470

From dholmes at openjdk.java.net  Fri Jun 11 05:02:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 05:02:50 GMT
Subject: [jdk17] RFR: 8268580:
 runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver
 mode
In-Reply-To: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>
References: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>
Message-ID: <C4amOFelMWa7oj8LLCRGf-_oe4vxQe_zT8bH0Nl6jec=.7f165305-b0d4-4c95-ae91-372e82d197fc@github.com>

On Fri, 11 Jun 2021 03:29:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that updates `TestLargePagesFlags.java` test to use `driver` mode?
> 
> testing: `runtime/memory/LargePages/`
> 
> Thanks,
> -- Igor

Seems fine and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/15

From david.holmes at oracle.com  Fri Jun 11 05:08:37 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Jun 2021 15:08:37 +1000
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <zJnLEV0T_c0sXpLMfRwhUasKZLo9mkTUJz0qybBB4do=.553438aa-e150-474c-a7d7-12a4255b32fe@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
 <zJnLEV0T_c0sXpLMfRwhUasKZLo9mkTUJz0qybBB4do=.553438aa-e150-474c-a7d7-12a4255b32fe@github.com>
Message-ID: <be195c05-79df-f075-3b20-99c29283811e@oracle.com>

Trying again to get some attention on this PR. :)

Thanks,
David

On 4/06/2021 11:06 am, David Holmes wrote:
> On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>  From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
>>
>> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
>>
>> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
>>
>> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
>>
>> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
>>
>> The logging strategy is as follows:
>> - info: show whether the new API is available or not
>> - debug: report failures that are ignored (as we fallback to debugger mechanism)
>> - trace: report successes for full tracking
>>
>> Testing:
>>    - internal self-verification in debug builds as previously described
>>   - verified the logging output on different Windows systems that have, and don't have, the new API
>>   - sanity testing for tiers 1-3
>>
>> Thanks,
>> David
> 
> I wonder if I could entice any of our Microsoft contributors to give this a technical review (even if not Reviewers) - @luhenry ?
> 
> Thanks
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4297
> 

From iignatyev at openjdk.java.net  Fri Jun 11 05:08:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 05:08:54 GMT
Subject: [jdk17] RFR: 8268580:
 runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver
 mode
In-Reply-To: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>
References: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>
Message-ID: <-g3OmVjL5odUFsOgt11GNbwpkW8NmyZhUFa5RhvwEQc=.13aa810d-8d02-4103-82eb-552359db6f33@github.com>

On Fri, 11 Jun 2021 03:29:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that updates `TestLargePagesFlags.java` test to use `driver` mode?
> 
> testing: `runtime/memory/LargePages/`
> 
> Thanks,
> -- Igor

Thanks, David

-------------

PR: https://git.openjdk.java.net/jdk17/pull/15

From iignatyev at openjdk.java.net  Fri Jun 11 05:08:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 05:08:55 GMT
Subject: [jdk17] Integrated: 8268580:
 runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver
 mode
In-Reply-To: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>
References: <3UejP7IBbJ7Bi5IFxKhx-weWvQYk2dOF_SyviEe4Tak=.45a34bf8-e620-487f-925c-24df800d190d@github.com>
Message-ID: <242basfZJnzYaQ97TN-Fz56PljVDrlSxP35GKdVnNxw=.53479f06-3eba-4581-a3bd-724c3fe6605b@github.com>

On Fri, 11 Jun 2021 03:29:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that updates `TestLargePagesFlags.java` test to use `driver` mode?
> 
> testing: `runtime/memory/LargePages/`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: a437ce83
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/a437ce839f749dab8c42611e0190ece5bea5d255
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8268580: runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver mode

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk17/pull/15

From dholmes at openjdk.java.net  Fri Jun 11 05:38:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 05:38:53 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <SRMnYsgn-UDwVaEM-TDK2vIZn5MCK2iYQ2TtbFiaZwc=.f5515459-4e96-44e0-afc6-111f67c39a66@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
 <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
 <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>
 <BLhkmfT1RAFxMhRhBd2XUVnDR7KCsuAcrSc0lYb5jPk=.f889fdff-a601-4df9-841c-aaa236be056d@github.com>
 <Q7EXm8STkVH2oE8Lf9Jvno7-TqtRxYosJVlDsJplQEc=.c5d10bff-a963-4ef6-8a93-7c6b67bae57b@github.com>
 <SRMnYsgn-UDwVaEM-TDK2vIZn5MCK2iYQ2TtbFiaZwc=.f5515459-4e96-44e0-afc6-111f67c39a66@github.com>
Message-ID: <EWPt-Orr1vVN5NZI7TYFQQydVJFkDmJe9MH0Rl8N-tI=.33d54443-186e-4799-ba4c-16b4e2704a41@github.com>

On Thu, 10 Jun 2021 19:11:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> It is the load/store of `uint _decorators;` that needs to be atomic.
>
> I can't overload copy constructor and assignment operator using Atomic because there are many places we don't need atomic operation at all. Of course, I can provide two member functions atomic_load/store for `LogDecorators`.  TBH, I feel I am uglifying code.  Actually I did it, the generated code is exactly same. that's why I am reluctant to use them.
> 
> Yes, the atomicity isn't provided by C++. It is provided by both c++ and underneath processors. As long as load/store are aligned and the ALU is 32-bit or wider,  store like c42 is atomic.
> 
> 
> 0000000000000c40 <LogOutput::set_decorators(LogDecorators const&)>:
>      c40:       8b 06                   mov    (%rsi),%eax
>      c42:       89 47 20                mov    %eax,0x20(%rdi)
>      c45:       c3                      retq
> 
> 
> A RCU algorithm never be straightforward. That's why I try to write comments here.  It's not me who introduce this code. I just try to explain how it works. 
> 
> How about this? Could you submit this patch to the internal test infra and see if it can pass tier1~tier7? if it can't, we refactor this code.

First my apologies for getting muddled by this code. We don't use class types in lock-free algorithms so don't have a means to express atomic updates to objects this way. We still need the accesses to be atomic, but have no way to express that in the source code when the code has been written this way.

The issue is not whether the generated code is exactly the same as it often will be, especially on x86. The issue is how we show in our source code that we have lock-free racy accesses to variables and that we are aware of this and have applied all the necessary atomic operations and/or orderAccess operations to ensure the races result in correct operation of the code. Unfortunately that is not currently feasible  due to the way this code has been written. I think fixing that aspect will need to be a future RFE.

I had already submitted tiers 1-3 with no problem, but have now submitted tiers 4-7.

I still need to re-examine the RCU code to understand the broader context here.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From dholmes at openjdk.java.net  Fri Jun 11 05:38:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 05:38:53 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <WEjqpbJLcd7x2h3ajnk3b4I-0vd9Z_z5Bn_5CB2jL14=.e3634bc6-5ac7-496d-b2f5-c15d50fa5112@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ky_t8xsEePauiwHBXdlVRMPaHznMXHtAypnZflHTL5E=.b8611fb6-7380-4b85-b874-fa203b05fd90@github.com>
 <yHhb13P8NtSswSfosmFyyLVIamxnNE7jYmBdvc75p9c=.59c0a0e8-6a22-4a97-90fb-c9babbb8a348@github.com>
 <VLpLtLoQWcu_7C04Rk3JZXEIcoh0k5IwzVzccxRgRdk=.e88175f0-58b6-4e72-a3fb-767b33a896d0@github.com>
 <AF_lWIIpinRYRu31FLLZHMy4M7HdKV-kaoVFHS8Xhwk=.f555e324-28cf-4058-9c08-2340ee61c692@github.com>
 <KSObw2sFy03s6d90rcmXsWlkvYx7FNjP_lO-xf5Rx9A=.a6643a65-e424-47a6-9325-b38558675228@github.com>
 <WEjqpbJLcd7x2h3ajnk3b4I-0vd9Z_z5Bn_5CB2jL14=.e3634bc6-5ac7-496d-b2f5-c15d50fa5112@github.com>
Message-ID: <bIzB1CkgrOC0Si67Kjjx3gRHBbyvkz5_0IRCFEl4KOA=.d37123b4-73d7-4fbf-aed5-2ee91d743710@github.com>

On Thu, 10 Jun 2021 19:18:00 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I have no idea why you mention volatile and jsr-133 here.
>> 
>> If there is an Atomic::add inside there then okay the necessary barrier may be in place. But it is not at all apparent there is an Atomic operation inside there, so given the order is important the comment needs to explain why an explicit barrier is not needed.
>
> The following code uses `Atomic::add`. Actually, there's a hidden 3rd argument. it's a default parameter and I highlight it.  It is the conservative memory order emits a full memory barrier. I double-check the implementations on  x86/aarch64 and powerpc.
> 
> 
> jint LogOutputList::increase_readers() {
>   jint result = Atomic::add(&_active_readers, 1, /*memory_order_conservative*/);
>   assert(_active_readers > 0, "Ensure we have consistent state");
>   return result;
> }

Thanks for adding the comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From stuefe at openjdk.java.net  Fri Jun 11 06:05:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Jun 2021 06:05:48 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <_g4cgZw3g_EhfQNIvW82vVF3CeTBQJrK6AT-KxqKaOY=.a481f367-b7b1-4df8-addd-b31c61f4c2dd@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

Hi David,

I think the original code was one of the first contributions I made to OpenJDK: https://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015528.html

I would not call it "weird" though. At that point it was the only available and officially documented way to set thread names on Windows.

I am not sure if the error check is worth the complexity, especially since it only kind of checks itself (we may just set and read an invisible variable for all we know). We had no such checks for the old version, nor for the linux implementation.

I read https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019. I believe the documentation is incorrect insofar as that the old version worked for WinDbg too, not only VS, I tested this in 2014. 

Cheers, Thomas

src/hotspot/os/windows/os_windows.cpp line 890:

> 888: // For dynamic lookup of SetThreadDescription API
> 889: typedef HRESULT (WINAPI *SetThreadDescriptionFnPtr)(HANDLE, PCWSTR);
> 890: typedef HRESULT (WINAPI *GetThreadDescriptionFnPtr)(HANDLE, PWSTR*);

DEBUG_ONLY?

src/hotspot/os/windows/os_windows.cpp line 930:

> 928:                                    thread_name,
> 929:                                    -1  // null-terminated
> 930:                                    );

Why not just use wcscmp? (WCHAR == wchar_t, and also you use %ls below which implies wchar_t, so you may use wcscmp here too).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From stuefe at openjdk.java.net  Fri Jun 11 06:21:52 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Jun 2021 06:21:52 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <mwg2Lgy5R9Z0FHdcvTFMfks6i14JFxvlOogxvpG9Sio=.4c8cf175-6ea6-410f-8b34-28a7d5ab9c0c@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

Another issue with the check just occurred to me which is that there may be (its not documented) a limit to the thread name length. There is one on Linux. Which means a check would need to do a substring comparison.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From david.holmes at oracle.com  Fri Jun 11 06:28:10 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Jun 2021 16:28:10 +1000
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <_g4cgZw3g_EhfQNIvW82vVF3CeTBQJrK6AT-KxqKaOY=.a481f367-b7b1-4df8-addd-b31c61f4c2dd@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
 <_g4cgZw3g_EhfQNIvW82vVF3CeTBQJrK6AT-KxqKaOY=.a481f367-b7b1-4df8-addd-b31c61f4c2dd@github.com>
Message-ID: <e316859d-61f9-e503-5649-7d84f2cd59d2@oracle.com>

Hi Thomas,

Thanks for taking a look at this.

On 11/06/2021 4:05 pm, Thomas Stuefe wrote:
> On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>  From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
>>
>> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
>>
>> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
>>
>> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
>>
>> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
>>
>> The logging strategy is as follows:
>> - info: show whether the new API is available or not
>> - debug: report failures that are ignored (as we fallback to debugger mechanism)
>> - trace: report successes for full tracking
>>
>> Testing:
>>    - internal self-verification in debug builds as previously described
>>   - verified the logging output on different Windows systems that have, and don't have, the new API
>>   - sanity testing for tiers 1-3
>>
>> Thanks,
>> David
> 
> Hi David,
> 
> I think the original code was one of the first contributions I made to OpenJDK: https://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015528.html
> 
> I would not call it "weird" though. At that point it was the only available and officially documented way to set thread names on Windows.

To be clear it isn't our use of this mechanism that is being labelled 
"weird" but the actual win32 mechanism itself. :)

> I am not sure if the error check is worth the complexity, especially since it only kind of checks itself (we may just set and read an invisible variable for all we know). We had no such checks for the old version, nor for the linux implementation.

For the old version and other platforms we can easily check the result 
using external tools, like debuggers and process viewers. But that is 
not the case for this new API. While the newer VS versions support it I 
don't think there would be a way to know that we are observing use of 
the old or the new API for certain (and I don't have direct access to VS 
anyway). Hence the attempt to at least sanity check - though you are 
right I may not actually have set the correct name in the first place. I 
thought about comparing with the passed in char* but the unicode 
gymnastics was more than I could stomach. :)

I'll respond to other comments in the PR UI.

Thanks,
David

> I read https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019. I believe the documentation is incorrect insofar as that the old version worked for WinDbg too, not only VS, I tested this in 2014.
> 
> Cheers, Thomas
> 
> src/hotspot/os/windows/os_windows.cpp line 890:
> 
>> 888: // For dynamic lookup of SetThreadDescription API
>> 889: typedef HRESULT (WINAPI *SetThreadDescriptionFnPtr)(HANDLE, PCWSTR);
>> 890: typedef HRESULT (WINAPI *GetThreadDescriptionFnPtr)(HANDLE, PWSTR*);
> 
> DEBUG_ONLY?
> 
> src/hotspot/os/windows/os_windows.cpp line 930:
> 
>> 928:                                    thread_name,
>> 929:                                    -1  // null-terminated
>> 930:                                    );
> 
> Why not just use wcscmp? (WCHAR == wchar_t, and also you use %ls below which implies wchar_t, so you may use wcscmp here too).
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4297
> 

From dholmes at openjdk.java.net  Fri Jun 11 06:30:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 06:30:53 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <_g4cgZw3g_EhfQNIvW82vVF3CeTBQJrK6AT-KxqKaOY=.a481f367-b7b1-4df8-addd-b31c61f4c2dd@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
 <_g4cgZw3g_EhfQNIvW82vVF3CeTBQJrK6AT-KxqKaOY=.a481f367-b7b1-4df8-addd-b31c61f4c2dd@github.com>
Message-ID: <XT3vOUXZhICKxwrOPzLXF2hWhfUs7FhSeBUym4y_U5A=.9c22c033-7104-4e06-b963-b614644f95f8@github.com>

On Fri, 11 Jun 2021 05:38:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
>> 
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
>> 
>> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
>> 
>> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
>> 
>> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
>> 
>> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
>> 
>> The logging strategy is as follows:
>> - info: show whether the new API is available or not
>> - debug: report failures that are ignored (as we fallback to debugger mechanism)
>> - trace: report successes for full tracking
>> 
>> Testing:
>>   - internal self-verification in debug builds as previously described
>>  - verified the logging output on different Windows systems that have, and don't have, the new API
>>  - sanity testing for tiers 1-3
>> 
>> Thanks,
>> David
>
> src/hotspot/os/windows/os_windows.cpp line 890:
> 
>> 888: // For dynamic lookup of SetThreadDescription API
>> 889: typedef HRESULT (WINAPI *SetThreadDescriptionFnPtr)(HANDLE, PCWSTR);
>> 890: typedef HRESULT (WINAPI *GetThreadDescriptionFnPtr)(HANDLE, PWSTR*);
> 
> DEBUG_ONLY?

As it is only a typedef I didn't think the DEBUG_ONLY ugliness was warranted.

> src/hotspot/os/windows/os_windows.cpp line 930:
> 
>> 928:                                    thread_name,
>> 929:                                    -1  // null-terminated
>> 930:                                    );
> 
> Why not just use wcscmp? (WCHAR == wchar_t, and also you use %ls below which implies wchar_t, so you may use wcscmp here too).

Simply because I wasn't aware of it. I'm not at all familiar with Unicode/string API's on Windows and just looked around for something that would seem to do the job. All these types seem to be wchar_t in some form under the covers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From david.holmes at oracle.com  Fri Jun 11 06:34:14 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Jun 2021 16:34:14 +1000
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <mwg2Lgy5R9Z0FHdcvTFMfks6i14JFxvlOogxvpG9Sio=.4c8cf175-6ea6-410f-8b34-28a7d5ab9c0c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
 <mwg2Lgy5R9Z0FHdcvTFMfks6i14JFxvlOogxvpG9Sio=.4c8cf175-6ea6-410f-8b34-28a7d5ab9c0c@github.com>
Message-ID: <7c16b29a-7234-6f4a-7e64-60a514402945@oracle.com>

On 11/06/2021 4:21 pm, Thomas Stuefe wrote:
> On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>  From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
>>
>> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
>>
>> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
>>
>> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
>>
>> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
>>
>> The logging strategy is as follows:
>> - info: show whether the new API is available or not
>> - debug: report failures that are ignored (as we fallback to debugger mechanism)
>> - trace: report successes for full tracking
>>
>> Testing:
>>    - internal self-verification in debug builds as previously described
>>   - verified the logging output on different Windows systems that have, and don't have, the new API
>>   - sanity testing for tiers 1-3
>>
>> Thanks,
>> David
> 
> Another issue with the check just occurred to me which is that there may be (its not documented) a limit to the thread name length. There is one on Linux. Which means a check would need to do a substring comparison.

I'm assuming that if no limitations are documented then they don't 
exist. AFAIK the debugger hook mechanism has no limits so I don't see 
why this should either.


Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4297
> 

From jiefu at openjdk.java.net  Fri Jun 11 06:38:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 11 Jun 2021 06:38:55 GMT
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
Message-ID: <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>

On Mon, 24 May 2021 09:10:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> this will, however, only solve the problem w/ the test; but I also share Thomas' [concern](https://github.com/openjdk/jdk/pull/4140#issuecomment-845836298)[*], we shouldn't need 1g (or even .5g) of heap space to eat up 20m of metaspace (even w/ small classes like `AnonkTestee01`), so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
>> 
>> -- Igor
>> 
>> [*] 
>>> What I am concerned about is that with there should not be that much variance in how much heap space we use. Sure you can set it to 1g or 2g, but something is clearly off. I get by on Linux x64 with 128m, on 32bit x86 with 256m (since we don't have CompressedClassPointers we need somewhat more heap). But needing 1g on aarch64 seems weird.
>
>> so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
> 
> Yes, I think that makes sense since all of our linux-aarch64 platforms couldn't reproduce the OOME except those of Oracle's .

> @DamonFool , the goal of this test is to check that in case of (nearly) exhaused metaspace defining classes via `MethodHandles.Lookup::defineHiddenClass` will lead to OOME, after your rewriting, this test doesn't serve that purpose anymore, now it just checks that runnig `java -version` w/ small metaspace will lead to OOME.
> 
> -- Igor

@tstuefe , do you also think we should revert this change and use `-XX:MaxRAMPercentage=25` to fix the bug?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140

From kbarrett at openjdk.java.net  Fri Jun 11 06:47:49 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 11 Jun 2021 06:47:49 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
Message-ID: <MeAhSAQhORSUxc2nk507m0i-HInkr9IBjioss7oCXf4=.58e3eafb-26fd-44b4-bac3-676103eb91d3@github.com>

On Mon, 7 Jun 2021 14:15:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   read once

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4363

From stefank at openjdk.java.net  Fri Jun 11 07:00:59 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 11 Jun 2021 07:00:59 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
Message-ID: <vnRTHpzAykmDBklXqBno7Mk0UT9DIK35WmY5uq1rd44=.1bf91ab2-429b-441a-838b-24755447e365@github.com>

On Mon, 7 Jun 2021 14:15:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
>> 
>> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
>> 
>> Testing: tier1, tier2, tier6, tier8
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   read once

Marked as reviewed by stefank (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From kbarrett at openjdk.java.net  Fri Jun 11 07:00:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 11 Jun 2021 07:00:59 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <RwCtWWoT06eAkHBsTaPCNnsxfLf2Y2d8Jz4EqOPgDgE=.3ae540eb-6c04-4193-af21-cff001be8ed9@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
 <RwCtWWoT06eAkHBsTaPCNnsxfLf2Y2d8Jz4EqOPgDgE=.3ae540eb-6c04-4193-af21-cff001be8ed9@github.com>
Message-ID: <NsIty2irEAbhQPXYdSPINCQv3pOqVm6u1rb5ihdQmOk=.e5359125-cc40-48b7-8524-b57b90743ab7@github.com>

On Thu, 10 Jun 2021 13:03:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Kim has been looking through the standards w.r.t. atomic and read-read coherence and has some insights. Could be worth reading:
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-June/052745.html

read-read coherence only applies to reads of the same atomic object.  That doesn't apply to the case at hand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From stefank at openjdk.java.net  Fri Jun 11 07:10:47 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 11 Jun 2021 07:10:47 GMT
Subject: RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left
 >= right) failed: avoid underflow [v2]
In-Reply-To: <NsIty2irEAbhQPXYdSPINCQv3pOqVm6u1rb5ihdQmOk=.e5359125-cc40-48b7-8524-b57b90743ab7@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
 <3NnHCZtn1Y8MsswZNng9xhZAeMI5Gb1E6iYpM5SH__k=.de74ab04-0bc2-438f-b0ed-1ba06d9f8357@github.com>
 <RwCtWWoT06eAkHBsTaPCNnsxfLf2Y2d8Jz4EqOPgDgE=.3ae540eb-6c04-4193-af21-cff001be8ed9@github.com>
 <NsIty2irEAbhQPXYdSPINCQv3pOqVm6u1rb5ihdQmOk=.e5359125-cc40-48b7-8524-b57b90743ab7@github.com>
Message-ID: <0pLbwxWKpKanebhNUnYXpgaGGmAHZ6vb0stTe15thh8=.fa91da42-69e6-4999-a6f6-34f8a65a10fa@github.com>

On Fri, 11 Jun 2021 06:57:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Kim has been looking through the standards w.r.t. atomic and read-read coherence and has some insights. Could be worth reading:
> > https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-June/052745.html
> 
> read-read coherence only applies to reads of the same atomic object. That doesn't apply to the case at hand.

Thanks for pointing this out. FWIW, the discussion above strayed away from the actual contents PR, and started to talk about the name and semantics of Atomic::load / relaxed atomic loads, in a more generic sense than the suggested usage of it in the patch above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From luhenry at openjdk.java.net  Fri Jun 11 08:31:49 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Fri, 11 Jun 2021 08:31:49 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <sC5VbSwzRAYHUk0ClDYnMecDxAkX4royo7BFL2ycNv0=.95726a7c-3560-4255-bd75-ab3c0cae713f@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

Looks good.

src/hotspot/os/windows/os_windows.cpp line 4372:

> 4370:   // Lookup SetThreadDescription - the docs state we must use runtime-linking of
> 4371:   // kernelbase.dll, so that is what we do.
> 4372:   HINSTANCE _kernelbase = LoadLibrary(TEXT("kernelbase.dll"));

`kernel32.dll` would be the better dll to look into (per https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription and the .NET source code).

-------------

Marked as reviewed by luhenry (Author).

PR: https://git.openjdk.java.net/jdk/pull/4297

From iignatyev at openjdk.java.net  Fri Jun 11 08:38:03 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 08:38:03 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need `/othervm`
Message-ID: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>

Hi all,

could you please review this small and trivial patch that removes `/othervm` from 3 `runtime/jni` tests?
from JBS:
> `runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java`, `checked/TestCheckedEnsureLocalCapacity.java`, and `atExit/TestAtExit.java` use `main/othervm` whereas in fact, they don't need `othervm`, and if we had CODETOOLS-7902658 implemented, they would have used `driver` mode. this RFE is to remove `/othervm`, so we at least won't waste time on creating a fresh JVM.

the patch explicitly sets `-Djava.library.path=` for the child processes so they are able to locate native libraries.

testing: `runtime/jni` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - copyright
 - 8268591

Changes: https://git.openjdk.java.net/jdk17/pull/18/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=18&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268591
  Stats: 18 lines in 3 files changed: 8 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/18.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/18/head:pull/18

PR: https://git.openjdk.java.net/jdk17/pull/18

From iignatyev at openjdk.java.net  Fri Jun 11 08:54:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 08:54:07 GMT
Subject: [jdk17] RFR: 8268594: runtime/handshake tests don't need WhiteBox
 after AOT removal
Message-ID: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>

Hi all,

could you please review this small test-only patch?
from JBS:
> `runtime/handshake/HandshakeTransitionTest.java` and `HandshakeTimeoutTest.java` use WhiteBox to check the value of `UseJVMCICompiler` as a workaround for AOT not supporting local handshakes (see [JDK-8191437](https://bugs.openjdk.java.net/browse/JDK-8191437)). 
>
> this isn't needed anymore and can be removed.

testing: `runtime/handshake` tests on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - 8268594

Changes: https://git.openjdk.java.net/jdk17/pull/19/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=19&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268594
  Stats: 26 lines in 2 files changed: 0 ins; 24 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/19/head:pull/19

PR: https://git.openjdk.java.net/jdk17/pull/19

From aph at openjdk.java.net  Fri Jun 11 09:00:54 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 11 Jun 2021 09:00:54 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <EnBO1NsLp7njPTkEcS74PHiJD0Yns11Iz4aORoOIR1E=.80b3bd51-f0b8-4137-9ce5-0488e3362169@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

Sort of. I'm trying to understand what can be AArch64-specific about any of this. If it's an AArch64-back-end-specific bug I'd like to know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4374

From iignatyev at openjdk.java.net  Fri Jun 11 09:18:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 09:18:06 GMT
Subject: [jdk17] RFR: 8268596: mark hotspot runtime/verifier tests which
 ignore external VM flags
Message-ID: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `verifier/TraceClassRes.java` test as it ignores all external flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright
 - 8268596

Changes: https://git.openjdk.java.net/jdk17/pull/20/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=20&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268596
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk17/pull/20

From iignatyev at openjdk.java.net  Fri Jun 11 09:19:01 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 09:19:01 GMT
Subject: [jdk17] RFR: 8268597: mark hotspot runtime/symboltable tests which
 ignore external VM flags
Message-ID: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `symboltable/ShortLivedSymbolCleanup.java` test as it ignores all external flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright
 - 8268597

Changes: https://git.openjdk.java.net/jdk17/pull/21/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=21&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268597
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/21/head:pull/21

PR: https://git.openjdk.java.net/jdk17/pull/21

From iignatyev at openjdk.java.net  Fri Jun 11 09:25:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 09:25:10 GMT
Subject: [jdk17] RFR: 8246498: mark hotspot runtime tests which ignore
 external VM flags
Message-ID: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `stringtable/StringTableVerifyTest.java` test as it ignores all external flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright
 - 8246498

Changes: https://git.openjdk.java.net/jdk17/pull/22/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=22&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246498
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/22.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/22/head:pull/22

PR: https://git.openjdk.java.net/jdk17/pull/22

From iignatyev at openjdk.java.net  Fri Jun 11 09:44:03 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 09:44:03 GMT
Subject: [jdk17] RFR: 8268599: mark hotspot runtime/sealedClasses tests which
 ignore external VM flags
Message-ID: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `runtime/sealedClasses` tests which ignore all external flags?

Thanks,
-- Igor

-------------

Commit messages:
 - 8268599

Changes: https://git.openjdk.java.net/jdk17/pull/23/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=23&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268599
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/23.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/23/head:pull/23

PR: https://git.openjdk.java.net/jdk17/pull/23

From iignatyev at openjdk.java.net  Fri Jun 11 09:50:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 09:50:10 GMT
Subject: [jdk17] RFR: 8268601: mark hotspot runtime/records tests which ignore
 external VM flags
Message-ID: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `RedefineRecord.java` test as it ignores all external flags?

Thanks,
-- Igor

-------------

Commit messages:
 - 8268601

Changes: https://git.openjdk.java.net/jdk17/pull/24/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=24&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268601
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/24.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/24/head:pull/24

PR: https://git.openjdk.java.net/jdk17/pull/24

From iignatyev at openjdk.java.net  Fri Jun 11 10:00:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 10:00:12 GMT
Subject: [jdk17] RFR: 8268602: a couple runtime/os tests don't check exit code
Message-ID: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>

Hi all,

could you please review this trivial and test-only patch that adds checks of exit code to two `runtime/os` tests?
from JBS:
> `runtime/os/TestUseCpuAllocPath.java` and `AvailableProcessors.java` spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors

testing: ``runtime/os` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - copyright
 - 8268602

Changes: https://git.openjdk.java.net/jdk17/pull/25/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=25&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268602
  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk17/pull/25

From david.holmes at oracle.com  Fri Jun 11 12:03:52 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Jun 2021 22:03:52 +1000
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <sC5VbSwzRAYHUk0ClDYnMecDxAkX4royo7BFL2ycNv0=.95726a7c-3560-4255-bd75-ab3c0cae713f@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
 <sC5VbSwzRAYHUk0ClDYnMecDxAkX4royo7BFL2ycNv0=.95726a7c-3560-4255-bd75-ab3c0cae713f@github.com>
Message-ID: <4fa99e1a-3d24-acd7-6dd7-962dbf1dd61a@oracle.com>

On 11/06/2021 6:31 pm, Ludovic Henry wrote:
> On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>  From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
>>
>> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
>>
>> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
>>
>> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
>>
>> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
>>
>> The logging strategy is as follows:
>> - info: show whether the new API is available or not
>> - debug: report failures that are ignored (as we fallback to debugger mechanism)
>> - trace: report successes for full tracking
>>
>> Testing:
>>    - internal self-verification in debug builds as previously described
>>   - verified the logging output on different Windows systems that have, and don't have, the new API
>>   - sanity testing for tiers 1-3
>>
>> Thanks,
>> David
> 
> Looks good.

Thanks for reviewing it!

> 
> src/hotspot/os/windows/os_windows.cpp line 4372:
> 
>> 4370:   // Lookup SetThreadDescription - the docs state we must use runtime-linking of
>> 4371:   // kernelbase.dll, so that is what we do.
>> 4372:   HINSTANCE _kernelbase = LoadLibrary(TEXT("kernelbase.dll"));
> 
> `kernel32.dll` would be the better dll to look into (per https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription and the .NET source code).

Those docs state:

"Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: 
SetThreadDescription is only available by Run Time Dynamic Linking in 
KernelBase.dll."

so if I use kernel32 does that mean it will fail on the above Windows 
versions? Is this suggesting I need to use a different dll depending on 
the actual Windows version?

Thanks,
David

> -------------
> 
> Marked as reviewed by luhenry (Author).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4297
> 

From dholmes at openjdk.java.net  Fri Jun 11 12:13:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 12:13:47 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
Message-ID: <JsQs8dL7PFpBbKtlJ29hi6T6LQbivcaTzuFpswX0aRY=.cced6e69-9c44-4062-bb3f-e7cb216b0f3e@github.com>

On Fri, 11 Jun 2021 08:31:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that removes `/othervm` from 3 `runtime/jni` tests?
> from JBS:
>> `runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java`, `checked/TestCheckedEnsureLocalCapacity.java`, and `atExit/TestAtExit.java` use `main/othervm` whereas in fact, they don't need `othervm`, and if we had CODETOOLS-7902658 implemented, they would have used `driver` mode. this RFE is to remove `/othervm`, so we at least won't waste time on creating a fresh JVM.
> 
> the patch explicitly sets `-Djava.library.path=` for the child processes so they are able to locate native libraries.
> 
> testing: `runtime/jni` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Hi Igor,

The test classes, run by jtreg, load native libraries (though they could possibly be refactored so that is not necessary) so I would expect we would want othervm here because we do not want to load multiple unrelated libraries in the shared VM implied by "main".

I also don't understand why you now need to set java.library.path explicitly in some of the tests ??

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk17/pull/18

From dholmes at openjdk.java.net  Fri Jun 11 12:19:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 12:19:51 GMT
Subject: [jdk17] RFR: 8268602: a couple runtime/os tests don't check exit
 code
In-Reply-To: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
References: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
Message-ID: <nLtqIemR8uBbeiZUn6pdjPqTEjUJG4BpqeYAvfVNf9Q=.33dcb1bf-d79d-4ffc-8d30-ac9d4537a958@github.com>

On Fri, 11 Jun 2021 09:51:24 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial and test-only patch that adds checks of exit code to two `runtime/os` tests?
> from JBS:
>> `runtime/os/TestUseCpuAllocPath.java` and `AvailableProcessors.java` spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
> 
> testing: ``runtime/os` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

The value of doing this seems marginal, but strictly speaking yes every test that launches  VM should check for a zero exit code. Arguably this should be built into the ProcessTools API so that we don't have to do it explicitly. The special case would be looking for a non-zero exit code.

In the case of failure it is more efficient to check the exit code first before potentially wasting time parsing output. But we probably don't care too much about that.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/25

From iignatyev at openjdk.java.net  Fri Jun 11 12:45:17 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 12:45:17 GMT
Subject: [jdk17] RFR: 8268602: a couple runtime/os tests don't check exit
 code [v2]
In-Reply-To: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
References: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
Message-ID: <wB0dmzeC6J-4w2GyBnQAelVwE8mN2yUDEcrBgd4bnzM=.01a83a7f-d6d6-4c64-8668-bf7b93bfe6af@github.com>

> Hi all,
> 
> could you please review this trivial and test-only patch that adds checks of exit code to two `runtime/os` tests?
> from JBS:
>> `runtime/os/TestUseCpuAllocPath.java` and `AvailableProcessors.java` spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
> 
> testing: ``runtime/os` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  check exit code first

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/25/files
  - new: https://git.openjdk.java.net/jdk17/pull/25/files/abaabc29..1c3cae32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=25&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=25&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk17/pull/25

From iignatyev at openjdk.java.net  Fri Jun 11 12:45:17 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 12:45:17 GMT
Subject: [jdk17] RFR: 8268602: a couple runtime/os tests don't check exit
 code
In-Reply-To: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
References: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
Message-ID: <wtcOXgP3DgGXf-6nLmp3Ei9Tegr9j6iTlIvgm1l7Y3o=.b40f6f5b-e168-4239-8374-27926581e7b3@github.com>

On Fri, 11 Jun 2021 09:51:24 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial and test-only patch that adds checks of exit code to two `runtime/os` tests?
> from JBS:
>> `runtime/os/TestUseCpuAllocPath.java` and `AvailableProcessors.java` spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
> 
> testing: ``runtime/os` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

thanks, David. I've moved `OutputAnalyzer::shouldHaveExitValue` calls. I agree that it makes sense to update ProcessTools API to always check exit code; I'll file an RFE for that.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/25

From iignatyev at openjdk.java.net  Fri Jun 11 12:45:18 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 12:45:18 GMT
Subject: [jdk17] Integrated: 8268602: a couple runtime/os tests don't check
 exit code
In-Reply-To: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
References: <sGaWtlmffqdKYI3tpqz5lHM2dlfqGaCEQQy8VQ7hPsU=.a169fd6b-04c4-4b78-87b7-2a86c017d251@github.com>
Message-ID: <brpR4rf7gNHFZOkQ7fba2fokgQHK8_L74tCrdE3CuQo=.bf1dfcde-0501-49cf-90fa-32f6b729e07d@github.com>

On Fri, 11 Jun 2021 09:51:24 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial and test-only patch that adds checks of exit code to two `runtime/os` tests?
> from JBS:
>> `runtime/os/TestUseCpuAllocPath.java` and `AvailableProcessors.java` spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
> 
> testing: ``runtime/os` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: cce8da2c
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/cce8da2c60812873b63de4e65bc992bc6d825fe1
Stats:     4 lines in 2 files changed: 2 ins; 0 del; 2 mod

8268602: a couple runtime/os tests don't check exit code

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk17/pull/25

From dholmes at openjdk.java.net  Fri Jun 11 12:49:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 12:49:51 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <ZPiav3ti_pmBc6jLuCl7wRnJIU_nqWgrALUNLcVCjoY=.658bbf09-4ba1-420c-a77b-fe4131732a22@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ZPiav3ti_pmBc6jLuCl7wRnJIU_nqWgrALUNLcVCjoY=.658bbf09-4ba1-420c-a77b-fe4131732a22@github.com>
Message-ID: <fdoBW2tGPck7Uc_wuhVxYqhcfClp-ROsrbHZOCXIobw=.8d57bd96-ccc3-4db1-b9d7-0636cd41f6d3@github.com>

On Thu, 10 Jun 2021 08:04:37 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments in LogTagSet::log().

Hi Xin,

Unfortunately the new test is crashing:

[ RUN      ] LogConfigurationTest.reconfigure_decorators_MT_vm
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb565530ee0, pid=24293, tid=24303
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-06-09-0450595.david.holmes.jdk-dev.git)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-06-09-0450595.david.holmes.jdk-dev.git, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0x6bee0]  flockfile+0x0
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to  testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/1/core.24293)
#
# An error report file with more information is saved as:
# testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/1/hs_err_pid24293.log
[       OK ] LogConfigurationTest.reconfigure_decorators_MT_vm (1018 ms)
[ RUN      ] LogConfigurationTest.reconfigure_tags_MT_vm
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

Current thread (0x000055cff4e59eb0):  Thread "AsyncLog Thread" [stack: 0x00007fb530d63000,0x00007fb530e63000] [id=24303]

Stack: [0x00007fb530d63000,0x00007fb530e63000],  sp=0x00007fb530e61ae8,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x6bee0]  flockfile+0x0
V  [libjvm.so+0x15fb542]  LogFileOutput::write_blocking(LogDecorations const&, char const*)+0x32
V  [libjvm.so+0x15f5b6d]  AsyncLogWriter::run()+0x35d
V  [libjvm.so+0x1c0c290]  Thread::call_run()+0x100
V  [libjvm.so+0x18d98ae]  thread_native_entry(Thread*)+0x10e


I'll try to investigate more on Monday

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From iignatyev at openjdk.java.net  Fri Jun 11 12:49:51 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 12:49:51 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <JsQs8dL7PFpBbKtlJ29hi6T6LQbivcaTzuFpswX0aRY=.cced6e69-9c44-4062-bb3f-e7cb216b0f3e@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
 <JsQs8dL7PFpBbKtlJ29hi6T6LQbivcaTzuFpswX0aRY=.cced6e69-9c44-4062-bb3f-e7cb216b0f3e@github.com>
Message-ID: <KJGymFPMU8PXFi26vUo97exjXont-AKGqhxOdjxoj7w=.075469b3-aada-4904-94c2-4345b677c91d@github.com>

On Fri, 11 Jun 2021 12:10:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The test classes, run by jtreg, load native libraries (though they could possibly be refactored so that is not necessary) so I would expect we would want othervm here because we do not want to load multiple unrelated libraries in the shared VM implied by "main".

`jtreg` uses a separate classloader for each test, and native libraries are to be unloaded when CL is GC'ed, so there should be no unrelated libraries in shared VMs.

> I also don't understand why you now need to set java.library.path explicitly in some of the tests ??

frankly, I don't fully understand why it's needed, but these tests started to fail w/ `UnsatisfiedLinkError` when I removed `/othervm` and setting `java.library.path` fixed the problem. I assumed it's because we don't set/propagate `LD_LIBRARY_PATH` (or its equivalent), yet all my attempts to reproduce this behavior and the problem w/ a small test case failed, I'll dig deeper next week.

Thanks,
-- Igor

-------------

PR: https://git.openjdk.java.net/jdk17/pull/18

From iignatyev at openjdk.java.net  Fri Jun 11 13:06:50 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 13:06:50 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <KJGymFPMU8PXFi26vUo97exjXont-AKGqhxOdjxoj7w=.075469b3-aada-4904-94c2-4345b677c91d@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
 <JsQs8dL7PFpBbKtlJ29hi6T6LQbivcaTzuFpswX0aRY=.cced6e69-9c44-4062-bb3f-e7cb216b0f3e@github.com>
 <KJGymFPMU8PXFi26vUo97exjXont-AKGqhxOdjxoj7w=.075469b3-aada-4904-94c2-4345b677c91d@github.com>
Message-ID: <OhkYWy0ZJfTek0b81YbnFcnzX4YpaCzUWRNV9vtO18I=.0de642ac-c054-45f3-947b-a32d93da5a7a@github.com>

On Fri, 11 Jun 2021 12:46:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> I also don't understand why you now need to set java.library.path explicitly in some of the tests ??
> frankly, I don't fully understand why it's needed, but these tests started to fail w/ `UnsatisfiedLinkError` when I removed `/othervm` and setting `java.library.path` fixed the problem. I assumed it's because we don't set/propagate `LD_LIBRARY_PATH` (or its equivalent), yet all my attempts to reproduce this behavior and the problem w/ a small test case failed, I'll dig deeper next week.

reproduced, as I assumed `LD_LIBRARY_PATH` isn't set in case of `@run main` and hence it doesn't get propagated to a spawn JVM which causes ULE. the reason I wasn't able to reproduce that before is the fact that `othervm` is a default mode and I didn't have `-agentvm` in my command line ?????

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk17/pull/18

From hseigel at openjdk.java.net  Fri Jun 11 13:06:59 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 11 Jun 2021 13:06:59 GMT
Subject: [jdk17] RFR: 8268596: mark hotspot runtime/verifier tests which
 ignore external VM flags
In-Reply-To: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
References: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
Message-ID: <_RrA-a0zQCxt0gJ86m4_zddCYAJVlog8for4sMXxR4U=.186f23bf-ab90-4cdf-bb45-66a38d6c2fcd@github.com>

On Fri, 11 Jun 2021 09:09:14 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `verifier/TraceClassRes.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Changes look good and trivial.
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/20

From ccheung at openjdk.java.net  Fri Jun 11 15:56:05 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Jun 2021 15:56:05 GMT
Subject: [jdk17] RFR: 8268522: InstanceKlass::can_be_verified_at_dumptime()
 returns opposite value
Message-ID: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>

Please review this small patch:

- correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
- modify the call sites accordingly.

- [x] mach5 tiers 1,2,3

-------------

Commit messages:
 - 8268522: InstanceKlass::can_be_verified_at_dumptime() returns opposite value

Changes: https://git.openjdk.java.net/jdk17/pull/31/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=31&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268522
  Stats: 15 lines in 5 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/31/head:pull/31

PR: https://git.openjdk.java.net/jdk17/pull/31

From iklam at openjdk.java.net  Fri Jun 11 15:59:47 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 11 Jun 2021 15:59:47 GMT
Subject: [jdk17] RFR: 8268470: CDS dynamic dump asserts with JFR
 RecordingStream
In-Reply-To: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
References: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
Message-ID: <7E3Av5JAVGBeQRq8bujeNMiUBKosx0mX1gfceqadq34=.ec38c303-d7a8-4475-a49a-7757acae5a5d@github.com>

On Thu, 10 Jun 2021 18:53:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During JFR startup, it redefines some of the builtin classes like `java/lang/Throwable`. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
> 
> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
> 
> - [x] mach5 tier1, tier2 (including the new test) (in progress)

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/9

From ccheung at openjdk.java.net  Fri Jun 11 16:10:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Jun 2021 16:10:58 GMT
Subject: [jdk17] RFR: 8268470: CDS dynamic dump asserts with JFR
 RecordingStream
In-Reply-To: <xFl4M8lywE32JNnj05HdEK5kJCP7WyG0psPZ51zGmfY=.42e1eadc-777f-4bcb-b209-fd604ffaa66a@github.com>
References: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
 <xFl4M8lywE32JNnj05HdEK5kJCP7WyG0psPZ51zGmfY=.42e1eadc-777f-4bcb-b209-fd604ffaa66a@github.com>
Message-ID: <Ak0A2JQmBUVKMpzr6bE0My7UTPDT7r86Zy1m9O4Hrlo=.3231838d-11db-415c-8ff5-57042e836d52@github.com>

On Thu, 10 Jun 2021 20:14:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> During JFR startup, it redefines some of the builtin classes like `java/lang/Throwable`. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
>> 
>> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
>> 
>> - [x] mach5 tier1, tier2 (including the new test) (in progress)
>
> LGTM.

@yminqi, @iklam Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/9

From ccheung at openjdk.java.net  Fri Jun 11 16:11:01 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Jun 2021 16:11:01 GMT
Subject: [jdk17] Integrated: 8268470: CDS dynamic dump asserts with JFR
 RecordingStream
In-Reply-To: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
References: <2Tij9IVvwkHedDrqvZ8OTSW3DxuLXDrKh-XGXUKNazM=.dcb1a1bc-d5b0-4fd6-90b5-6324ba88e645@github.com>
Message-ID: <xBgmORoy0IMP2GluZ2thKdT63G7tPZUC4WvINvHXpoY=.370ed3a9-8e33-4ea7-9fe3-09a63d5614bd@github.com>

On Thu, 10 Jun 2021 18:53:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During JFR startup, it redefines some of the builtin classes like `java/lang/Throwable`. Later, when a subclass of Throwable is loaded, it will inherit the redefined version of Throwable which will not be inside the buffer space or mapped static archive.
> 
> To fix this bug, in `SystemDictionaryShared::check_for_exclusion_impl()`, instead of only checking if the class has been redefined, it also checks if any of its super types has been redefined. If so, exclude the class from the archive.
> 
> - [x] mach5 tier1, tier2 (including the new test) (in progress)

This pull request has now been integrated.

Changeset: 01054e6f
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/01054e6f5ab75dd1b7d3e82be0eb83f14a7add15
Stats:     170 lines in 4 files changed: 169 ins; 0 del; 1 mod

8268470: CDS dynamic dump asserts with JFR RecordingStream

Reviewed-by: minqi, iklam

-------------

PR: https://git.openjdk.java.net/jdk17/pull/9

From dcubed at openjdk.java.net  Fri Jun 11 16:24:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 16:24:59 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <sQhvWdLUIgdqQLe0wsiTJlVwdhT5Jutap7d74qy1V6s=.2ebd2b3a-210e-4eab-a1b0-08d7ee8247e7@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

It's only ProblemListed on linux-aarch64 because that's the only place
where we've seen the issue in Mach5. It's just that simple. Doesn't mean
that it won't show up on any other config with enough runs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4374

From stuefe at openjdk.java.net  Fri Jun 11 17:16:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Jun 2021 17:16:55 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <XT3vOUXZhICKxwrOPzLXF2hWhfUs7FhSeBUym4y_U5A=.9c22c033-7104-4e06-b963-b614644f95f8@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
 <_g4cgZw3g_EhfQNIvW82vVF3CeTBQJrK6AT-KxqKaOY=.a481f367-b7b1-4df8-addd-b31c61f4c2dd@github.com>
 <XT3vOUXZhICKxwrOPzLXF2hWhfUs7FhSeBUym4y_U5A=.9c22c033-7104-4e06-b963-b614644f95f8@github.com>
Message-ID: <NN9oTO0sX8N9BhIJX4qDECWPmvuGkm2FWWPKm3V-vc4=.8c8577c9-a4af-4ea3-ad78-d90e4c52a782@github.com>

On Fri, 11 Jun 2021 06:26:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 890:
>> 
>>> 888: // For dynamic lookup of SetThreadDescription API
>>> 889: typedef HRESULT (WINAPI *SetThreadDescriptionFnPtr)(HANDLE, PCWSTR);
>>> 890: typedef HRESULT (WINAPI *GetThreadDescriptionFnPtr)(HANDLE, PWSTR*);
>> 
>> DEBUG_ONLY?
>
> As it is only a typedef I didn't think the DEBUG_ONLY ugliness was warranted.

Hmm, I find it inconsistent, but its also not important. Okay.

>> src/hotspot/os/windows/os_windows.cpp line 930:
>> 
>>> 928:                                    thread_name,
>>> 929:                                    -1  // null-terminated
>>> 930:                                    );
>> 
>> Why not just use wcscmp? (WCHAR == wchar_t, and also you use %ls below which implies wchar_t, so you may use wcscmp here too).
>
> Simply because I wasn't aware of it. I'm not at all familiar with Unicode/string API's on Windows and just looked around for something that would seem to do the job. All these types seem to be wchar_t in some form under the covers.

Yes, its not that well documented. But we fall back to wcs... APIs in a couple of places. But if your code works there is no need to change it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From stuefe at openjdk.java.net  Fri Jun 11 17:16:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Jun 2021 17:16:54 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <rtRuEwbYzDDwlqDEsTB9S1rJE-Q3hrhCrKeKy6AjGwQ=.c7821d91-fcdc-4417-b2bf-5f3e605db668@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

Hi David, I am fine with your change in its current form (if you want to reshape it, I'll look again). I see no other concerns.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4297

From ccheung at openjdk.java.net  Fri Jun 11 18:13:20 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Jun 2021 18:13:20 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
Message-ID: <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>

> Please review this small patch:
> 
> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
> - modify the call sites accordingly.
> 
> - [x] mach5 tiers 1,2,3

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  Change _is_shared_old_klass to _verified_at_dump_time

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/31/files
  - new: https://git.openjdk.java.net/jdk17/pull/31/files/5f1774ba..c43bcb07

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=31&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=31&range=00-01

  Stats: 15 lines in 6 files changed: 2 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/31/head:pull/31

PR: https://git.openjdk.java.net/jdk17/pull/31

From dcubed at openjdk.java.net  Fri Jun 11 20:22:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 20:22:10 GMT
Subject: [jdk17] RFR: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
Message-ID: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>

Target is JDK17:
A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.

-------------

Commit messages:
 - 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64

Changes: https://git.openjdk.java.net/jdk17/pull/33/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=33&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268630
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/33/head:pull/33

PR: https://git.openjdk.java.net/jdk17/pull/33

From erikj at openjdk.java.net  Fri Jun 11 20:22:10 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 11 Jun 2021 20:22:10 GMT
Subject: [jdk17] RFR: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
In-Reply-To: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
References: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
Message-ID: <lBToA8OUmklbNT4w2NlbnoY3KTWs8EtftIJK7kqsvnM=.c7a4123f-761d-4079-925c-bfb58b816c03@github.com>

On Fri, 11 Jun 2021 20:11:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Target is JDK17:
> A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/33

From dcubed at openjdk.java.net  Fri Jun 11 20:27:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 20:27:51 GMT
Subject: [jdk17] RFR: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
In-Reply-To: <lBToA8OUmklbNT4w2NlbnoY3KTWs8EtftIJK7kqsvnM=.c7a4123f-761d-4079-925c-bfb58b816c03@github.com>
References: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
 <lBToA8OUmklbNT4w2NlbnoY3KTWs8EtftIJK7kqsvnM=.c7a4123f-761d-4079-925c-bfb58b816c03@github.com>
Message-ID: <BO0nwEoQzoQj6S-z85pQ0y5qxNXfxw-NagQsWANkaZk=.d3b295d5-2d3d-4e0f-862d-75adddf3caca@github.com>

On Fri, 11 Jun 2021 20:16:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Target is JDK17:
>> A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.
>
> Marked as reviewed by erikj (Reviewer).

@erikj79 - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/33

From dcubed at openjdk.java.net  Fri Jun 11 20:27:52 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 20:27:52 GMT
Subject: [jdk17] Integrated: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
In-Reply-To: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
References: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
Message-ID: <K3BukckOSBOvc9YwKH1hUFK4OB3q7z2iWu5JzbeZ50U=.32f50b87-a11c-4182-87cf-00ea0ffa959d@github.com>

On Fri, 11 Jun 2021 20:11:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Target is JDK17:
> A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.

This pull request has now been integrated.

Changeset: 6171ae45
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6171ae455288a74c4c3dcec6983515db04bdc360
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64

Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/jdk17/pull/33

From cjplummer at openjdk.java.net  Fri Jun 11 21:05:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 11 Jun 2021 21:05:50 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <MrEis4l3FwRX0J6KPUiTttw1HYgVO2Fg83RS5QHVcWY=.899d0f52-17d4-4c34-8505-1feba9383926@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

This is an SA bug, so it could be an issue with the aarch64 support in SA.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4374

From dholmes at openjdk.java.net  Fri Jun 11 22:09:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 22:09:50 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
Message-ID: <PtLkoRVfomT6LdbVcPPbLKsvteXRoJbrKhxcAJHRUps=.2a141343-42df-44cc-998f-ab21ea522141@github.com>

On Fri, 11 Jun 2021 18:13:20 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this small patch:
>> 
>> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
>> - modify the call sites accordingly.
>> 
>> - [x] mach5 tiers 1,2,3
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change _is_shared_old_klass to _verified_at_dump_time

Hi Calvin,

The logic negation seems fine.

The change to shared_old_class also seems fine in general.

But there is one change that I'm querying as it seems a functional change.

Thanks,
David

src/hotspot/share/oops/klassVtable.cpp line 1098:

> 1096:      !MetaspaceShared::remapped_readwrite() &&
> 1097:      m->method_holder()->verified_at_dump_time() &&
> 1098:      klass->verified_at_dump_time()) {

This change seems to go beyond the simple logic negation. Why the change here?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/31

From ccheung at openjdk.java.net  Fri Jun 11 22:35:52 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Jun 2021 22:35:52 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <PtLkoRVfomT6LdbVcPPbLKsvteXRoJbrKhxcAJHRUps=.2a141343-42df-44cc-998f-ab21ea522141@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
 <PtLkoRVfomT6LdbVcPPbLKsvteXRoJbrKhxcAJHRUps=.2a141343-42df-44cc-998f-ab21ea522141@github.com>
Message-ID: <aZtW9-a-Gcdnrp9O7V9gHkUF15sbaoQFVCf5r6HCCeM=.b6428f4a-0205-4bc5-a2e0-0c94e974abd6@github.com>

On Fri, 11 Jun 2021 22:03:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change _is_shared_old_klass to _verified_at_dump_time
>
> src/hotspot/share/oops/klassVtable.cpp line 1098:
> 
>> 1096:      !MetaspaceShared::remapped_readwrite() &&
>> 1097:      m->method_holder()->verified_at_dump_time() &&
>> 1098:      klass->verified_at_dump_time()) {
> 
> This change seems to go beyond the simple logic negation. Why the change here?

Hi David,

Thanks for your review!

The block of code you mentioned is being called during runtime. So it is more consistent to call `verified_at_dump_time()`.

Thanks,
Calvin

-------------

PR: https://git.openjdk.java.net/jdk17/pull/31

From minqi at openjdk.java.net  Sat Jun 12 00:14:53 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Sat, 12 Jun 2021 00:14:53 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
Message-ID: <x7qMdbQVwXkXexuIz18W1JM-g0DS0z-k3qrxa_p79YE=.cb731e81-1f48-4cd5-8ae7-14664ac7b8c6@github.com>

On Fri, 11 Jun 2021 18:13:20 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this small patch:
>> 
>> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
>> - modify the call sites accordingly.
>> 
>> - [x] mach5 tiers 1,2,3
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change _is_shared_old_klass to _verified_at_dump_time

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/31

From iklam at openjdk.java.net  Sat Jun 12 01:14:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 12 Jun 2021 01:14:52 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
Message-ID: <Ywj1Prdcdb0fYxrofZQzBG8ta1aOsauL74aq0yreu2s=.caba82d3-ef23-49c3-8177-f7ec8a71d038@github.com>

On Fri, 11 Jun 2021 18:13:20 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this small patch:
>> 
>> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
>> - modify the call sites accordingly.
>> 
>> - [x] mach5 tiers 1,2,3
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change _is_shared_old_klass to _verified_at_dump_time

Just one request for change. The rest looks good to me.

src/hotspot/share/oops/instanceKlass.cpp line 2407:

> 2405:   if (!can_be_verified_at_dumptime()) {
> 2406:     // Clear the _verified_at_dump_time bit.
> 2407:     clear_verified_at_dump_time();

I think it's better to change this to 


if (can_be_verified_at_dumptime()) {
  // Remember this so we can avoid walking the hierarchy at runtime.
  set_verified_at_dump_time();


and do not set this bit inside `Klass::Klass()`. This way, all the code that changes this bit are kept in a single place.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/31

From ccheung at openjdk.java.net  Sat Jun 12 01:46:11 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Sat, 12 Jun 2021 01:46:11 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v3]
In-Reply-To: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
Message-ID: <XmmXiIjgKk356SsBVrZAfvcOrqTj0B0Qxnz5VDK42pE=.d3c71959-44b7-42a4-a791-0846677392bb@github.com>

> Please review this small patch:
> 
> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
> - modify the call sites accordingly.
> 
> - [x] mach5 tiers 1,2,3

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  Set the _verified_at_dump_time bit in InstanceKlass::remove_unshareable_info()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/31/files
  - new: https://git.openjdk.java.net/jdk17/pull/31/files/c43bcb07..874e83ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=31&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=31&range=01-02

  Stats: 7 lines in 3 files changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/31/head:pull/31

PR: https://git.openjdk.java.net/jdk17/pull/31

From ccheung at openjdk.java.net  Sat Jun 12 01:50:57 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Sat, 12 Jun 2021 01:50:57 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <Ywj1Prdcdb0fYxrofZQzBG8ta1aOsauL74aq0yreu2s=.caba82d3-ef23-49c3-8177-f7ec8a71d038@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
 <Ywj1Prdcdb0fYxrofZQzBG8ta1aOsauL74aq0yreu2s=.caba82d3-ef23-49c3-8177-f7ec8a71d038@github.com>
Message-ID: <j0oOFEKjk4kZSY09K5bAh-1BIl6In2UxFs77gdJLLs0=.99ce837c-417c-4da6-96af-c05940a72bb6@github.com>

On Sat, 12 Jun 2021 01:05:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change _is_shared_old_klass to _verified_at_dump_time
>
> src/hotspot/share/oops/instanceKlass.cpp line 2407:
> 
>> 2405:   if (!can_be_verified_at_dumptime()) {
>> 2406:     // Clear the _verified_at_dump_time bit.
>> 2407:     clear_verified_at_dump_time();
> 
> I think it's better to change this to 
> 
> 
> if (can_be_verified_at_dumptime()) {
>   // Remember this so we can avoid walking the hierarchy at runtime.
>   set_verified_at_dump_time();
> 
> 
> and do not set this bit inside `Klass::Klass()`. This way, all the code that changes this bit are kept in a single place.

Thanks Ioi.

I've pushed an update with your suggestion.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/31

From ccheung at openjdk.java.net  Sat Jun 12 01:50:56 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Sat, 12 Jun 2021 01:50:56 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v2]
In-Reply-To: <x7qMdbQVwXkXexuIz18W1JM-g0DS0z-k3qrxa_p79YE=.cb731e81-1f48-4cd5-8ae7-14664ac7b8c6@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <l6WsYLe1hCfCSL1Eu9IlOPoDiQXSTNEw5wnx6HQNL9o=.be5f109b-1caa-4bd0-923f-8a191c59afb7@github.com>
 <x7qMdbQVwXkXexuIz18W1JM-g0DS0z-k3qrxa_p79YE=.cb731e81-1f48-4cd5-8ae7-14664ac7b8c6@github.com>
Message-ID: <c7MiI7TIHHZLh8W4WvG_hP5uf2hMpdEV3DxrkvZkjWg=.e4f0cad3-8508-4d28-9c2d-220bcaa73607@github.com>

On Sat, 12 Jun 2021 00:12:06 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> LGTM.

Thanks Yumin.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/31

From luhenry at openjdk.java.net  Sat Jun 12 05:27:54 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Sat, 12 Jun 2021 05:27:54 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <M0KNIoxAEUrZxbx_60dYRAaPlnPPYxzz8uyNowko0bY=.018c9c8d-4ab7-4e86-b6de-ba287b1d0950@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

Let?s go with `kernelbase.dll` then since it?s a superset of `kernel32.dll`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From iklam at openjdk.java.net  Sat Jun 12 05:33:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 12 Jun 2021 05:33:50 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v3]
In-Reply-To: <XmmXiIjgKk356SsBVrZAfvcOrqTj0B0Qxnz5VDK42pE=.d3c71959-44b7-42a4-a791-0846677392bb@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <XmmXiIjgKk356SsBVrZAfvcOrqTj0B0Qxnz5VDK42pE=.d3c71959-44b7-42a4-a791-0846677392bb@github.com>
Message-ID: <DPR5xK947aLI27q5E3J9wINnBzkijlr_5-H6LDlDT5A=.33d52aa0-b27a-45d3-bb90-78cdcdc21921@github.com>

On Sat, 12 Jun 2021 01:46:11 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this small patch:
>> 
>> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
>> - modify the call sites accordingly.
>> 
>> - [x] mach5 tiers 1,2,3
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the _verified_at_dump_time bit in InstanceKlass::remove_unshareable_info()

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/31

From dholmes at openjdk.java.net  Sat Jun 12 05:33:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 12 Jun 2021 05:33:51 GMT
Subject: [jdk17] RFR: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value [v3]
In-Reply-To: <XmmXiIjgKk356SsBVrZAfvcOrqTj0B0Qxnz5VDK42pE=.d3c71959-44b7-42a4-a791-0846677392bb@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
 <XmmXiIjgKk356SsBVrZAfvcOrqTj0B0Qxnz5VDK42pE=.d3c71959-44b7-42a4-a791-0846677392bb@github.com>
Message-ID: <Ti4FyRM-8Fm8MaxuEfKBcOid7oC8LcW0c-rgqnvY6z8=.9adf28cc-e786-4f62-8f20-bf576eac1414@github.com>

On Sat, 12 Jun 2021 01:46:11 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this small patch:
>> 
>> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
>> - modify the call sites accordingly.
>> 
>> - [x] mach5 tiers 1,2,3
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the _verified_at_dump_time bit in InstanceKlass::remove_unshareable_info()

Update looks good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/31

From azvegint at openjdk.java.net  Sat Jun 12 13:56:02 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 12 Jun 2021 13:56:02 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
In-Reply-To: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
References: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
Message-ID: <4dwImZNFNNS_4ACZiei-NM30OodbKSepiGtGvC9qM6E=.a6a5255c-78c0-4a58-964c-1d53c860d651@github.com>

On Sat, 12 Jun 2021 13:45:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4478

From dcubed at openjdk.java.net  Sat Jun 12 13:56:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Jun 2021 13:56:02 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
Message-ID: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>

A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.

-------------

Commit messages:
 - 8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode

Changes: https://git.openjdk.java.net/jdk/pull/4478/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4478&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268644
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4478.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4478/head:pull/4478

PR: https://git.openjdk.java.net/jdk/pull/4478

From dcubed at openjdk.java.net  Sat Jun 12 13:56:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Jun 2021 13:56:02 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
In-Reply-To: <4dwImZNFNNS_4ACZiei-NM30OodbKSepiGtGvC9qM6E=.a6a5255c-78c0-4a58-964c-1d53c860d651@github.com>
References: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
 <4dwImZNFNNS_4ACZiei-NM30OodbKSepiGtGvC9qM6E=.a6a5255c-78c0-4a58-964c-1d53c860d651@github.com>
Message-ID: <en__U9mtvLfwiQ7ouK6Ub7CbgiGI6x8JkFymA1-zA6Q=.6c9d4c41-b55b-4439-b11e-d6886cb9f58c@github.com>

On Sat, 12 Jun 2021 13:48:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4478

From dcubed at openjdk.java.net  Sat Jun 12 13:56:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Jun 2021 13:56:03 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
In-Reply-To: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
References: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
Message-ID: <txcbKEVb7WHs7b4fdfSBpXVjLvODBdcnZ9us80x-Fdc=.c9a271a6-2fbf-487d-aa8b-d39fa9adbf2a@github.com>

On Sat, 12 Jun 2021 13:45:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.

This pull request has now been integrated.

Changeset: 90c1034c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90c1034cd4077e63afc0aad53191a04699a816ce
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.java.net/jdk/pull/4478

From xliu at openjdk.java.net  Sun Jun 13 01:14:05 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 13 Jun 2021 01:14:05 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM is
 exiting.
Message-ID: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>

All 3 semaphores used by AsyncLogWriter are static member data. C++ runtime on
MacOS deletes them. Currently, AsyncLog Thread doesn't exit. Semaphore_wait/signal
returns with KERN_INVALID_NAME(15) if those semaphore are destroyed. 

This patch change those to regular data members. This prevents from deleting.

-------------

Commit messages:
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Changes: https://git.openjdk.java.net/jdk/pull/4479/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268638
  Stats: 28 lines in 3 files changed: 10 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4479/head:pull/4479

PR: https://git.openjdk.java.net/jdk/pull/4479

From xliu at openjdk.java.net  Sun Jun 13 04:48:03 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 13 Jun 2021 04:48:03 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v2]
In-Reply-To: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
Message-ID: <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>

> All 3 semaphores used by AsyncLogWriter are static member data. C++ runtime on
> MacOS deletes them. Currently, AsyncLog Thread doesn't exit. Semaphore_wait/signal
> returns with KERN_INVALID_NAME(15) if those semaphore are destroyed. 
> 
> This patch change those to regular data members. This prevents from deleting.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Support --with-debug-level=optimized.
  
  release build with debug level optimized doesn't define PRODUCT.
  use ASSERT instead.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4479/files
  - new: https://git.openjdk.java.net/jdk/pull/4479/files/634c164b..b7f853de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4479/head:pull/4479

PR: https://git.openjdk.java.net/jdk/pull/4479

From dholmes at openjdk.java.net  Sun Jun 13 22:19:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Jun 2021 22:19:59 GMT
Subject: Integrated: 8257038: Remove expired flags in JDK 18
In-Reply-To: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
References: <Ni88zK0PH5WAlOWF9C6qxdShO8fjQZ94WKPKE9iPGyI=.0b8489ed-03bf-4247-8492-51afd1f40ee6@github.com>
Message-ID: <SBiZB_knrEuFCcY5YccndTtOcLZNyJt5fYVODhdzQWA=.95929b1c-f90a-425f-a50c-c387bcf65d6f@github.com>

On Thu, 10 Jun 2021 23:15:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple start of release update:
>  - remove 4 expired flags
>  - move the now obsoleted flags to the obsoleted flag section
>  - update the dummy obsoleted flag
> 
> None of the expired flags were documented so no updated needed to any docs in that regard.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 1ba4e0ca
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1ba4e0cada031407a17a665cf24b03bacb59cdbb
Stats:     17 lines in 1 file changed: 5 ins; 9 del; 3 mod

8257038: Remove expired flags in JDK 18

Reviewed-by: kbarrett, ccheung

-------------

PR: https://git.openjdk.java.net/jdk/pull/4470

From dholmes at openjdk.java.net  Mon Jun 14 04:02:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 04:02:01 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
Message-ID: <Z_wlKyj1FRY2dEzQ7gX7TvMH3nnhxMk7Vjtu-lzVLpQ=.88a0305f-193a-42bd-a22f-0b75b46db5fc@github.com>

On Fri, 11 Jun 2021 08:31:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that removes `/othervm` from 3 `runtime/jni` tests?
> from JBS:
>> `runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java`, `checked/TestCheckedEnsureLocalCapacity.java`, and `atExit/TestAtExit.java` use `main/othervm` whereas in fact, they don't need `othervm`, and if we had CODETOOLS-7902658 implemented, they would have used `driver` mode. this RFE is to remove `/othervm`, so we at least won't waste time on creating a fresh JVM.
> 
> the patch explicitly sets `-Djava.library.path=` for the child processes so they are able to locate native libraries.
> 
> testing: `runtime/jni` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thanks for the explanations Igor.

David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/18

From dholmes at openjdk.java.net  Mon Jun 14 04:23:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 04:23:51 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v2]
In-Reply-To: <ZPiav3ti_pmBc6jLuCl7wRnJIU_nqWgrALUNLcVCjoY=.658bbf09-4ba1-420c-a77b-fe4131732a22@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <ZPiav3ti_pmBc6jLuCl7wRnJIU_nqWgrALUNLcVCjoY=.658bbf09-4ba1-420c-a77b-fe4131732a22@github.com>
Message-ID: <9cdBA4BudN_LwoCgq_ViurSmIR0H64m1MOP3NNj2C9E=.37b856b4-b409-46fe-a81d-31076a30506a@github.com>

On Thu, 10 Jun 2021 08:04:37 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments in LogTagSet::log().

> Unfortunately the new test is crashing:
> ...
> I'll try to investigate more on Monday

I think the fix for 8268165 is missing. That would explain the crashes.
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Mon Jun 14 04:51:28 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 14 Jun 2021 04:51:28 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v3]
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <F4jJasSlw0rdvDsE_26GXgqZf5uoV1Ie6_PcD3fKOl4=.27658df6-757b-4b2e-8e66-86e7b55f143c@github.com>

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

Xin Liu 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-8267952
 - Add comments in LogTagSet::log().
 - 8267952: async logging supports to dynamically change tags and decorators

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4408/files
  - new: https://git.openjdk.java.net/jdk/pull/4408/files/6e51b96e..4d2de713

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=01-02

  Stats: 21258 lines in 511 files changed: 15622 ins; 3201 del; 2435 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408

PR: https://git.openjdk.java.net/jdk/pull/4408

From kbarrett at openjdk.java.net  Mon Jun 14 05:04:01 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 14 Jun 2021 05:04:01 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v3]
In-Reply-To: <EWPt-Orr1vVN5NZI7TYFQQydVJFkDmJe9MH0Rl8N-tI=.33d54443-186e-4799-ba4c-16b4e2704a41@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <K6WWBNa6B5J9w1ztbuCu9R7bGHK4n7GmQWIq-wNRzIM=.8cea0379-ccf6-4ce1-9d42-a907e976f001@github.com>
 <YuQngpKodyVwzhtE2A3AP5Mw77sEj3jbvmIOFkAZ0KE=.e3174cf4-ae42-4e7a-9d47-3851715703f7@github.com>
 <VGLRP62Mc033XCdXclVlTNdwL3DK-bbCaYMfvXL4XlM=.37f7ef18-8050-4caf-9418-5a97e7c0f22d@github.com>
 <34x964DX_4gJ9IoLIBbGSkZLuuVqA63Dsp3uMYl0sL8=.c4837074-4ace-49bc-b4e3-4b8969dcfcb5@github.com>
 <BLhkmfT1RAFxMhRhBd2XUVnDR7KCsuAcrSc0lYb5jPk=.f889fdff-a601-4df9-841c-aaa236be056d@github.com>
 <Q7EXm8STkVH2oE8Lf9Jvno7-TqtRxYosJVlDsJplQEc=.c5d10bff-a963-4ef6-8a93-7c6b67bae57b@github.com>
 <SRMnYsgn-UDwVaEM-TDK2vIZn5MCK2iYQ2TtbFiaZwc=.f5515459-4e96-44e0-afc6-111f67c39a66@github.com>
 <EWPt-Orr1vVN5NZI7TYFQQydVJFkDmJe9MH0Rl8N-tI=.33d54443-186e-4799-ba4c-16b4e2704a41@github.com>
Message-ID: <eid-QdwwpZPJvEmaDZIBlmHXbUHQPaI75frJUrqy4ZU=.3d8ae52f-fc61-4bf7-b60b-9760289a4fcd@github.com>

On Fri, 11 Jun 2021 05:34:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I can't overload copy constructor and assignment operator using Atomic because there are many places we don't need atomic operation at all. Of course, I can provide two member functions atomic_load/store for `LogDecorators`.  TBH, I feel I am uglifying code.  Actually I did it, the generated code is exactly same. that's why I am reluctant to use them.
>> 
>> Yes, the atomicity isn't provided by C++. It is provided by both c++ and underneath processors. As long as load/store are aligned and the ALU is 32-bit or wider,  store like c42 is atomic.
>> 
>> 
>> 0000000000000c40 <LogOutput::set_decorators(LogDecorators const&)>:
>>      c40:       8b 06                   mov    (%rsi),%eax
>>      c42:       89 47 20                mov    %eax,0x20(%rdi)
>>      c45:       c3                      retq
>> 
>> 
>> A RCU algorithm never be straightforward. That's why I try to write comments here.  It's not me who introduce this code. I just try to explain how it works. 
>> 
>> How about this? Could you submit this patch to the internal test infra and see if it can pass tier1~tier7? if it can't, we refactor this code.
>
> First my apologies for getting muddled by this code. We don't use class types in lock-free algorithms so don't have a means to express atomic updates to objects this way. We still need the accesses to be atomic, but have no way to express that in the source code when the code has been written this way.
> 
> The issue is not whether the generated code is exactly the same as it often will be, especially on x86. The issue is how we show in our source code that we have lock-free racy accesses to variables and that we are aware of this and have applied all the necessary atomic operations and/or orderAccess operations to ensure the races result in correct operation of the code. Unfortunately that is not currently feasible  due to the way this code has been written. I think fixing that aspect will need to be a future RFE.
> 
> I had already submitted tiers 1-3 with no problem, but have now submitted tiers 4-7.
> 
> I still need to re-examine the RCU code to understand the broader context here.
> 
> Thanks.

[Not a review, just a drive-by comment.]
> We don't use class types in lock-free algorithms so don't have a means to
> express atomic updates to objects this way."

That isn't true. `oop` (when `CHECK_UNHANDLED_OOPS`) and `markWord` are the
first two that come to mind (there are some others). This is accomplished by
specializing PrimitiveConversions::Translate<> for these classes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From dholmes at openjdk.java.net  Mon Jun 14 05:41:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 05:41:52 GMT
Subject: [jdk17] RFR: 8268597: mark hotspot runtime/symboltable tests
 which ignore external VM flags
In-Reply-To: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
References: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
Message-ID: <Kq08bKsAsWRynXhRo9DRJJYhgb_5ZEqj2BUSpIwsNbY=.49ee9862-c67d-40a3-9b78-0eebdedacae4@github.com>

On Fri, 11 Jun 2021 09:13:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `symboltable/ShortLivedSymbolCleanup.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Seems fine and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/21

From dholmes at openjdk.java.net  Mon Jun 14 05:43:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 05:43:52 GMT
Subject: [jdk17] RFR: 8268594: runtime/handshake tests don't need WhiteBox
 after AOT removal
In-Reply-To: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
References: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
Message-ID: <f6CdixR9p6f5-uor70hjq332I8ntNb55PnK1b7Nsivo=.16e6d728-3bf8-441e-a8e4-791655f617b2@github.com>

On Fri, 11 Jun 2021 08:45:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> `runtime/handshake/HandshakeTransitionTest.java` and `HandshakeTimeoutTest.java` use WhiteBox to check the value of `UseJVMCICompiler` as a workaround for AOT not supporting local handshakes (see [JDK-8191437](https://bugs.openjdk.java.net/browse/JDK-8191437)). 
>>
>> this isn't needed anymore and can be removed.
> 
> testing: `runtime/handshake` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Seems fine.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/19

From dholmes at openjdk.java.net  Mon Jun 14 05:47:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 05:47:06 GMT
Subject: [jdk17] RFR: 8268599: mark hotspot runtime/sealedClasses tests
 which ignore external VM flags
In-Reply-To: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
References: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
Message-ID: <PbOC23zp3mQa_GnCaGooQyoCfMa9SmlWwsVcG3Ens1E=.81a03862-5201-43ff-8816-58d3dca1660c@github.com>

On Fri, 11 Jun 2021 09:36:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `runtime/sealedClasses` tests which ignore all external flags?
> 
> Thanks,
> -- Igor

Seems fine and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/23

From dholmes at openjdk.java.net  Mon Jun 14 05:47:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 05:47:25 GMT
Subject: [jdk17] RFR: 8268601: mark hotspot runtime/records tests which
 ignore external VM flags
In-Reply-To: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
References: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
Message-ID: <wZItG0yA86rJESODvvJk0hvy8ZMcy4tU478Cuie3VQA=.7ec49d07-d1cb-4ce6-8f2c-b988b185c90e@github.com>

On Fri, 11 Jun 2021 09:43:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `RedefineRecord.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Seems fine and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/24

From xliu at openjdk.java.net  Mon Jun 14 06:59:02 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 14 Jun 2021 06:59:02 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v3]
In-Reply-To: <F4jJasSlw0rdvDsE_26GXgqZf5uoV1Ie6_PcD3fKOl4=.27658df6-757b-4b2e-8e66-86e7b55f143c@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <F4jJasSlw0rdvDsE_26GXgqZf5uoV1Ie6_PcD3fKOl4=.27658df6-757b-4b2e-8e66-86e7b55f143c@github.com>
Message-ID: <-asP9LJcd38w0MZsXkjxdFUrpCUw3XlVrLwy5iR3_20=.53641a74-c21d-4819-a7ea-89f1ce8745e3@github.com>

On Mon, 14 Jun 2021 04:51:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> Xin Liu 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-8267952
>  - Add comments in LogTagSet::log().
>  - 8267952: async logging supports to dynamically change tags and decorators

hi, Kim, 

Thanks for the head-up. 

I did prepare a patch to support Atomic::store. I think I followed what you guys did. 
https://cr.openjdk.java.net/~xliu/8267952/atomic_store_LogDecorators.diff

Because this patch uses some C++ tricks(well, advanced techniques), I have to convince myself that it's necessary. so far, I found that it always generates the same store instructions in x86_64.

@dholmes-ora 
The biggest concern is the MT-safety. Users can potentially change unified logging configurations anytime in the presence of dcmd. That's why I added 2 concurrent gtests to demonstrate it's MT-safe no matter it's synchronous logging or async logging.  We must be sure that SEGV fault never happen. 

As far as I known, there are 2 reasons why we can see that crash sight. 

1.  `LogConfiguration::configure_output` may be still lack of a memory barrier somewhere. 
Some logs directed to output[idx] can still enqueue after `AsyncLogWriter::flush()`. delete_output(idx) is the hazard. 

If so, synchronous logging should observe the same problem. The fact is we only observed the crash in AsyncLog Thread. 
Further, I ran `LogConfigurationTest.reconfigure_tags_MT` a couple of hours on x86_64 and aarch64 individually.  I still can't capture the crash. 

2. LogFileOutput::rotate() may nullify _stream. 
yes, I missed bugfix JDK-8268165, but this patch uses "filecount=0" to prevent log from rotating in  `LogConfigurationTest.reconfigure_tags_MT`.  In my understanding, rotate() should not be invoked by this test.  

I have merged the master branch, which includes 8268165. Could you try it again and see if it will still crash at the same place?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From mgronlun at openjdk.java.net  Mon Jun 14 10:43:57 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 14 Jun 2021 10:43:57 GMT
Subject: Integrated: 8267579: Thread::cooked_allocated_bytes() hits
 assert(left >= right) failed: avoid underflow
In-Reply-To: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
References: <lMJhY07TyBkYAY2Vid6YssTmXVU1vFBJm6g3T1RQLck=.c89c478d-a4d2-48b0-b7f9-440ee286670b@github.com>
Message-ID: <ManLWbwQXNGXF66B0tv6kzkekeOBRrTF_PsMUxara8o=.be39958c-ebc3-49bf-99fb-5c9ce6cdb2d0@github.com>

On Fri, 4 Jun 2021 15:30:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This is a workaround to avoid hitting the assert that was recently added to pointer_delta(). 
> 
> The implementation of cooked_allocated_bytes() is perhaps questionable, in that it reads tlab pointers optimistically. However, the functionality has been in place for a long time, and the impact of changing its behavior more substantially is unknown at this time, hence this defensive workaround to reduce noise and problems seen in general testing.
> 
> Testing: tier1, tier2, tier6, tier8
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: c4207355
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4207355d3fc19687c72f47edf21611ffed7efaf
Stats:     21 lines in 3 files changed: 20 ins; 0 del; 1 mod

8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow

Reviewed-by: dcubed, stefank, kbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/4363

From dholmes at openjdk.java.net  Mon Jun 14 11:01:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Jun 2021 11:01:03 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v2]
In-Reply-To: <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>
Message-ID: <QvztHpLKVY3qRVjiE7xAjg0XmpjFpQS4UlkJ_q7DYvA=.96d92386-80c4-495b-9c22-2e86a5047cfe@github.com>

On Sun, 13 Jun 2021 04:48:03 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> All 3 semaphores used by AsyncLogWriter are static member data. C++ runtime on
>> MacOS deletes them. Currently, AsyncLog Thread doesn't exit. Semaphore_wait/signal
>> returns with KERN_INVALID_NAME(15) if those semaphore are destroyed. 
>> 
>> This patch change those to regular data members. This prevents from deleting.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support --with-debug-level=optimized.
>   
>   release build with debug level optimized doesn't define PRODUCT.
>   use ASSERT instead.

Changes requested by dholmes (Reviewer).

src/hotspot/share/logging/logAsyncWriter.cpp line 36:

> 34:  public:
> 35:   AsyncLogLocker(Semaphore* sem): _sem(sem) {
> 36:     assert(sem != nullptr && sem->value() == 1,

The value() check is not necessary. Please do not pollute the Semaphore API with this.

Rather than passing the Semaphore in it should just be accessed directly as there is only one Semaphore to ever be used here. Make AsyncLogLocker a friend class to allow access.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From ccheung at openjdk.java.net  Mon Jun 14 15:05:54 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 14 Jun 2021 15:05:54 GMT
Subject: [jdk17] Integrated: 8268522:
 InstanceKlass::can_be_verified_at_dumptime() returns opposite value
In-Reply-To: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
References: <p35Fech5r__yq9GDkhtQTOGKmgEPB2nXkdUW12xSmuQ=.0ce1087f-508f-43ad-935b-e4986cbd26c3@github.com>
Message-ID: <WeSM-nFRR-ES9MEQcS3svWA-RmgFH_ovy8FYVD9RX58=.10a9d264-8466-4c31-bdf2-cb103cb27b92@github.com>

On Fri, 11 Jun 2021 15:48:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small patch:
> 
> - correct the return value of `InstanceKlass::can_be_verified_at_dumptime()` to match the function's name;
> - modify the call sites accordingly.
> 
> - [x] mach5 tiers 1,2,3

This pull request has now been integrated.

Changeset: c088d093
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/c088d093e2e73fd0739d9e96f9f5ea67a01ae06c
Stats:     25 lines in 8 files changed: 0 ins; 0 del; 25 mod

8268522: InstanceKlass::can_be_verified_at_dumptime() returns opposite value

Reviewed-by: dholmes, minqi, iklam

-------------

PR: https://git.openjdk.java.net/jdk17/pull/31

From psandoz at openjdk.java.net  Mon Jun 14 15:56:55 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 14 Jun 2021 15:56:55 GMT
Subject: Withdrawn: 8268353: Test libsvml.so is and is not present in jdk image
In-Reply-To: <VMlYhPaPnz1Kq4XyHYUYfyWjOfqbzE0ox4LzVn4cQHU=.bc57df75-0e51-42c8-9a90-8d318a700a06@github.com>
References: <VMlYhPaPnz1Kq4XyHYUYfyWjOfqbzE0ox4LzVn4cQHU=.bc57df75-0e51-42c8-9a90-8d318a700a06@github.com>
Message-ID: <a1KXyn4N0zck8R7J24fV9rLq2vrGgZs2v5wqPgCzVHA=.8c0e31a7-6044-4171-8913-d6b8206edd1f@github.com>

On Tue, 8 Jun 2021 23:27:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4421

From psandoz at openjdk.java.net  Mon Jun 14 16:14:25 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 14 Jun 2021 16:14:25 GMT
Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk
 image
Message-ID: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>

Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

-------------

Commit messages:
 - 8268353: Test libsvml.so is and is not present in jdk image

Changes: https://git.openjdk.java.net/jdk17/pull/47/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=47&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268353
  Stats: 99 lines in 2 files changed: 96 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/47/head:pull/47

PR: https://git.openjdk.java.net/jdk17/pull/47

From hseigel at openjdk.java.net  Mon Jun 14 17:44:52 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 14 Jun 2021 17:44:52 GMT
Subject: [jdk17] RFR: 8268598: mark hotspot runtime/stringtable tests
 which ignore external VM flags
In-Reply-To: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
References: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
Message-ID: <y2R5xjv0ovygBvOL4r6ZNF00e1mQ5x04wa7AsALGAbg=.b1b063d8-7d38-4f31-9db5-d1ed07c58b09@github.com>

On Fri, 11 Jun 2021 09:17:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `stringtable/StringTableVerifyTest.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Looks good an trivial.
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/22

From david.holmes at oracle.com  Mon Jun 14 22:19:08 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Jun 2021 08:19:08 +1000
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v3]
In-Reply-To: <-asP9LJcd38w0MZsXkjxdFUrpCUw3XlVrLwy5iR3_20=.53641a74-c21d-4819-a7ea-89f1ce8745e3@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <F4jJasSlw0rdvDsE_26GXgqZf5uoV1Ie6_PcD3fKOl4=.27658df6-757b-4b2e-8e66-86e7b55f143c@github.com>
 <-asP9LJcd38w0MZsXkjxdFUrpCUw3XlVrLwy5iR3_20=.53641a74-c21d-4819-a7ea-89f1ce8745e3@github.com>
Message-ID: <8f262b53-2755-b898-4a3a-c35412d42039@oracle.com>

On 14/06/2021 4:59 pm, Xin Liu wrote:
> On Mon, 14 Jun 2021 04:51:28 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>>> The regression test discovers a race condition in LogTagSet::log() even with
>>> synchronous logging. It's not MT-safe if context switch happens between the
>>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>>
>> Xin Liu 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-8267952
>>   - Add comments in LogTagSet::log().
>>   - 8267952: async logging supports to dynamically change tags and decorators
> 
> hi, Kim,
> 
> Thanks for the head-up.
> 
> I did prepare a patch to support Atomic::store. I think I followed what you guys did.
> https://cr.openjdk.java.net/~xliu/8267952/atomic_store_LogDecorators.diff
> 
> Because this patch uses some C++ tricks(well, advanced techniques), I have to convince myself that it's necessary. so far, I found that it always generates the same store instructions in x86_64.
> 
> @dholmes-ora
> The biggest concern is the MT-safety. Users can potentially change unified logging configurations anytime in the presence of dcmd. That's why I added 2 concurrent gtests to demonstrate it's MT-safe no matter it's synchronous logging or async logging.  We must be sure that SEGV fault never happen.
> 
> As far as I known, there are 2 reasons why we can see that crash sight.
> 
> 1.  `LogConfiguration::configure_output` may be still lack of a memory barrier somewhere.
> Some logs directed to output[idx] can still enqueue after `AsyncLogWriter::flush()`. delete_output(idx) is the hazard.
> 
> If so, synchronous logging should observe the same problem. The fact is we only observed the crash in AsyncLog Thread.
> Further, I ran `LogConfigurationTest.reconfigure_tags_MT` a couple of hours on x86_64 and aarch64 individually.  I still can't capture the crash.
> 
> 2. LogFileOutput::rotate() may nullify _stream.
> yes, I missed bugfix JDK-8268165, but this patch uses "filecount=0" to prevent log from rotating in  `LogConfigurationTest.reconfigure_tags_MT`.  In my understanding, rotate() should not be invoked by this test.
> 
> I have merged the master branch, which includes 8268165. Could you try it again and see if it will still crash at the same place?

The updated branch passes the tier6 testing that previously failed. If 
rotate() should not be being used by the test, yet the rotate() fix has 
addressed the crashes, then apparently something else must be happening 
here that is not fully understood.

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4408
> 

From xliu at openjdk.java.net  Mon Jun 14 23:33:25 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 14 Jun 2021 23:33:25 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v3]
In-Reply-To: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
Message-ID: <GsmEYvkJU3jpy_KGqpQb0Pmpm-wp-g4W_AW97Zel344=.8cfed28c-8d55-4a49-a215-5c6553cb0806@github.com>

> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
> 
> This patch change those to regular data members. This prevents from deleting.
> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Change AsyncLogLocker to SemaphoreLock.
  
  Per reviewer's feedback, Semaphore declares SemaphoreLocker as a friend.
  now SemaphoreLocker is a general RAII class.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4479/files
  - new: https://git.openjdk.java.net/jdk/pull/4479/files/b7f853de..63e1fddf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=01-02

  Stats: 29 lines in 2 files changed: 18 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4479/head:pull/4479

PR: https://git.openjdk.java.net/jdk/pull/4479

From xliu at openjdk.java.net  Mon Jun 14 23:40:47 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 14 Jun 2021 23:40:47 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v2]
In-Reply-To: <QvztHpLKVY3qRVjiE7xAjg0XmpjFpQS4UlkJ_q7DYvA=.96d92386-80c4-495b-9c22-2e86a5047cfe@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>
 <QvztHpLKVY3qRVjiE7xAjg0XmpjFpQS4UlkJ_q7DYvA=.96d92386-80c4-495b-9c22-2e86a5047cfe@github.com>
Message-ID: <tG9b4vMtEITMZv-g6f3eoEgLET05wSPtkS76qMZMC7g=.b6b83144-3d5d-433b-bd28-c89190ec6fc2@github.com>

On Mon, 14 Jun 2021 10:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support --with-debug-level=optimized.
>>   
>>   release build with debug level optimized doesn't define PRODUCT.
>>   use ASSERT instead.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 36:
> 
>> 34:  public:
>> 35:   AsyncLogLocker(Semaphore* sem): _sem(sem) {
>> 36:     assert(sem != nullptr && sem->value() == 1,
> 
> The value() check is not necessary. Please do not pollute the Semaphore API with this.
> 
> Rather than passing the Semaphore in it should just be accessed directly as there is only one Semaphore to ever be used here. Make AsyncLogLocker a friend class to allow access.

Thanks.  I remove Semaphore::value() and declare friend class SemaphoreLocker there. 

My intention is to do a sanity check. A semaphore can be used to implement a low-level lock if and only if its value is 1. It means that only one thread can enter the critical region at any time.  However, it's error-prone for the RAII class to accept any arbitrary semaphore. It's because its value could be any non-negative number.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From coleenp at openjdk.java.net  Tue Jun 15 00:53:50 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 15 Jun 2021 00:53:50 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class loading
Message-ID: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>

We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.

Tested with tier1-3 in mach5.

-------------

Commit messages:
 - Remove unnecessary char_converter

Changes: https://git.openjdk.java.net/jdk/pull/4173/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4173&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267870
  Stats: 76 lines in 5 files changed: 1 ins; 66 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4173/head:pull/4173

PR: https://git.openjdk.java.net/jdk/pull/4173

From dholmes at openjdk.java.net  Tue Jun 15 01:59:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 01:59:45 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v2]
In-Reply-To: <3U9zATSE_9idr9Ib8_tVBqYqqiQGI1CnqoIhfDHJ_qc=.860079a7-6491-48ee-8101-9def637ded4e@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>
 <QvztHpLKVY3qRVjiE7xAjg0XmpjFpQS4UlkJ_q7DYvA=.96d92386-80c4-495b-9c22-2e86a5047cfe@github.com>
 <tG9b4vMtEITMZv-g6f3eoEgLET05wSPtkS76qMZMC7g=.b6b83144-3d5d-433b-bd28-c89190ec6fc2@github.com>
 <3U9zATSE_9idr9Ib8_tVBqYqqiQGI1CnqoIhfDHJ_qc=.860079a7-6491-48ee-8101-9def637ded4e@github.com>
Message-ID: <gBjln7YHMGUWNjllrDkB-sPGQlXKueyGsdhN9k91mm0=.0fbf278b-ea02-436b-96b6-0778f95180e0@github.com>

On Tue, 15 Jun 2021 01:55:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks.  I remove Semaphore::value() and declare friend class SemaphoreLocker there. 
>> 
>> My intention is to do a sanity check. A semaphore can be used to implement a low-level lock if and only if its value is 1. It means that only one thread can enter the critical region at any time.  However, it's error-prone for the RAII class to accept any arbitrary semaphore. It's because its value could be any non-negative number.
>
> I guess I wasn't clear enough.
> 
> Please do not make any changes to the Semaphore class. This "value" is not needed in general and not needed for your sanity checking.
> 
> The Semaphore _lock is defined in the AsyncLogWriter class and initialized to 1 so it can be used to mimic a mutual exclusion lock. This does not need to be sanity checked as it is all handled within a small chunk of code. The AsyncLogLocker does not take a semaphore, it is a friend of AsyncLogWriter and accesses _lock directly.
> 
> Thanks,
> David

PS. If it were warranted, the way to do your "sanity check" would be to introduce a BinarySemaphore class that always initializes to a count of 1. But we do not need this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From dholmes at openjdk.java.net  Tue Jun 15 01:59:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 01:59:45 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v2]
In-Reply-To: <tG9b4vMtEITMZv-g6f3eoEgLET05wSPtkS76qMZMC7g=.b6b83144-3d5d-433b-bd28-c89190ec6fc2@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>
 <QvztHpLKVY3qRVjiE7xAjg0XmpjFpQS4UlkJ_q7DYvA=.96d92386-80c4-495b-9c22-2e86a5047cfe@github.com>
 <tG9b4vMtEITMZv-g6f3eoEgLET05wSPtkS76qMZMC7g=.b6b83144-3d5d-433b-bd28-c89190ec6fc2@github.com>
Message-ID: <3U9zATSE_9idr9Ib8_tVBqYqqiQGI1CnqoIhfDHJ_qc=.860079a7-6491-48ee-8101-9def637ded4e@github.com>

On Mon, 14 Jun 2021 23:38:01 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 36:
>> 
>>> 34:  public:
>>> 35:   AsyncLogLocker(Semaphore* sem): _sem(sem) {
>>> 36:     assert(sem != nullptr && sem->value() == 1,
>> 
>> The value() check is not necessary. Please do not pollute the Semaphore API with this.
>> 
>> Rather than passing the Semaphore in it should just be accessed directly as there is only one Semaphore to ever be used here. Make AsyncLogLocker a friend class to allow access.
>
> Thanks.  I remove Semaphore::value() and declare friend class SemaphoreLocker there. 
> 
> My intention is to do a sanity check. A semaphore can be used to implement a low-level lock if and only if its value is 1. It means that only one thread can enter the critical region at any time.  However, it's error-prone for the RAII class to accept any arbitrary semaphore. It's because its value could be any non-negative number.

I guess I wasn't clear enough.

Please do not make any changes to the Semaphore class. This "value" is not needed in general and not needed for your sanity checking.

The Semaphore _lock is defined in the AsyncLogWriter class and initialized to 1 so it can be used to mimic a mutual exclusion lock. This does not need to be sanity checked as it is all handled within a small chunk of code. The AsyncLogLocker does not take a semaphore, it is a friend of AsyncLogWriter and accesses _lock directly.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From dholmes at openjdk.java.net  Tue Jun 15 02:16:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 02:16:42 GMT
Subject: RFR: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <UiDehom3MEpNczJ7GRZAMc-wmQjlvGHt-tGi4FRoigg=.0a5ed10a-ddc4-4b62-ad07-b13aa2ab6df8@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

Thanks again for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From dholmes at openjdk.java.net  Tue Jun 15 02:16:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 02:16:43 GMT
Subject: Integrated: 8238649: Call new Win32 API SetThreadDescription in
 os::set_native_thread_name
In-Reply-To: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
References: <rZkA66yBFiX0edfF3W_wa0953KCmt92P5Cry283kd_Q=.b5c7dfbf-244e-4849-ac7a-a8ff16d8595c@github.com>
Message-ID: <FW5ZHVYakokHVGtNBOkWx025-APiUBDsLei0W2GlVjg=.7e3c5808-cb0b-4694-a46f-0fd9a3437aa2@github.com>

On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
> 
> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
> 
> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
> 
> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
> 
> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
> 
> The logging strategy is as follows:
> - info: show whether the new API is available or not
> - debug: report failures that are ignored (as we fallback to debugger mechanism)
> - trace: report successes for full tracking
> 
> Testing:
>   - internal self-verification in debug builds as previously described
>  - verified the logging output on different Windows systems that have, and don't have, the new API
>  - sanity testing for tiers 1-3
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 9f3c7e74
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9f3c7e74ff00a7550742ed8b9d6671c2d4bb6041
Stats:     75 lines in 2 files changed: 74 ins; 0 del; 1 mod

8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name

Co-authored-by: Markus GaisBauer <markus.gaisbauer at dynatrace.com>
Reviewed-by: stuefe, luhenry

-------------

PR: https://git.openjdk.java.net/jdk/pull/4297

From dholmes at openjdk.java.net  Tue Jun 15 03:26:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 03:26:48 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading
In-Reply-To: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
Message-ID: <U20Z6tFeuC--JWe2QIHZuaqu8ot29bHJJg3bcwsc8B0=.ae96f4dd-a5b9-472a-92e0-00b17fb029f3@github.com>

On Mon, 24 May 2021 20:24:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
> 
> Tested with tier1-3 in mach5.

Hi Coleen,

Looks like a nice simplification if we never need a general purpose conversion utility.

I take it that Symbol::as_klass_external_name works correctly regardless of whether the name may be unicode or not? i.e that a `/` is always truly a slash and not part of some unicode sequence?

Thanks,
David

src/hotspot/share/classfile/javaAssertions.cpp line 139:

> 137:   for (index = len - 1; p != 0; p = p->next(), --index) {
> 138:     assert(index >= 0, "length does not match list");
> 139:     TempNewSymbol name = SymbolTable::new_symbol(p->name());

Why do we need a temp symbol?

src/hotspot/share/classfile/javaClasses.hpp line 231:

> 229: 
> 230:   // Conversion between '.' and '/' formats, and allocate a String from the result.
> 231:   static Handle externalize_classname(Symbol* java_string, TRAPS);

Nit: java_name might be more apt.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4173

From xliu at openjdk.java.net  Tue Jun 15 05:40:46 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 15 Jun 2021 05:40:46 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <8f262b53-2755-b898-4a3a-c35412d42039@oracle.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <8f262b53-2755-b898-4a3a-c35412d42039@oracle.com>
Message-ID: <oc2ls6rqfeStHlw8mx7pzcNBKRjaAUhvV_pF3nAjPas=.c5b1e81d-fdd1-43a5-a42e-6537789aab14@github.com>

On Mon, 14 Jun 2021 22:21:13 GMT, David Holmes <david.holmes at oracle.com> wrote:

> The updated branch passes the tier6 testing that previously failed. If
rotate() should not be being used by the test, yet the rotate() fix has
addressed the crashes, then apparently something else must be happening
here that is not fully understood.

Thanks for the feedback. To be honest, I am not sure what the root cause is.
I ran those two concurrent tests in hours as follows on different platforms, I have never seen a single crash. If I can have a reproducible, I will certainly figure out why and fix it. 

Now I intend to believe it's an external factor which caused it fails.  Those two tests don't trigger log rotation, but other gtests may do. Perhaps Oracle Linux mounts a small partition on /tmp.

My comment is like "a theory of operation". I try to document the original author's intention.  IMHO, it's thread-safe. 
Do you mind trying that patch again?  Maybe we were just lucky.


[ RUN      ] LogConfigurationTest.reconfigure_decorators_MT_vm
[       OK ] LogConfigurationTest.reconfigure_decorators_MT_vm (3601037 ms)
[ RUN      ] LogConfigurationTest.reconfigure_tags_MT_vm
[       OK ] LogConfigurationTest.reconfigure_tags_MT_vm (3600112 ms)


thanks,
--lx

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Tue Jun 15 06:19:15 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 15 Jun 2021 06:19:15 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v4]
In-Reply-To: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
Message-ID: <kd2LxaZevNcXRLidXmNMHw9tdRqwiQwgK3L1NrQaEDU=.f2654b02-4dbf-4ba1-90ef-88fa0541b3ba@github.com>

> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
> 
> This patch change those to regular data members. This prevents from deleting.
> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Do not do sanity check for AsyncLogLocker

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4479/files
  - new: https://git.openjdk.java.net/jdk/pull/4479/files/63e1fddf..e683f30b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=02-03

  Stats: 29 lines in 2 files changed: 0 ins; 21 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4479/head:pull/4479

PR: https://git.openjdk.java.net/jdk/pull/4479

From xliu at openjdk.java.net  Tue Jun 15 06:19:28 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 15 Jun 2021 06:19:28 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v2]
In-Reply-To: <gBjln7YHMGUWNjllrDkB-sPGQlXKueyGsdhN9k91mm0=.0fbf278b-ea02-436b-96b6-0778f95180e0@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <WtNWoNuegizV0fXZKqtpe38vGq-cov_1sgLkFRysgGk=.1d1263f4-7d33-4f32-97cd-0517fedc4fd0@github.com>
 <QvztHpLKVY3qRVjiE7xAjg0XmpjFpQS4UlkJ_q7DYvA=.96d92386-80c4-495b-9c22-2e86a5047cfe@github.com>
 <tG9b4vMtEITMZv-g6f3eoEgLET05wSPtkS76qMZMC7g=.b6b83144-3d5d-433b-bd28-c89190ec6fc2@github.com>
 <3U9zATSE_9idr9Ib8_tVBqYqqiQGI1CnqoIhfDHJ_qc=.860079a7-6491-48ee-8101-9def637ded4e@github.com>
 <gBjln7YHMGUWNjllrDkB-sPGQlXKueyGsdhN9k91mm0=.0fbf278b-ea02-436b-96b6-0778f95180e0@github.com>
Message-ID: <Ol8BnLROQtfMD4jfX4WQWdIpOyzEciGRbKMi2xcxKX0=.41bddd37-7267-4624-947f-39a05d6a8f76@github.com>

On Tue, 15 Jun 2021 01:56:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I guess I wasn't clear enough.
>> 
>> Please do not make any changes to the Semaphore class. This "value" is not needed in general and not needed for your sanity checking.
>> 
>> The Semaphore _lock is defined in the AsyncLogWriter class and initialized to 1 so it can be used to mimic a mutual exclusion lock. This does not need to be sanity checked as it is all handled within a small chunk of code. The AsyncLogLocker does not take a semaphore, it is a friend of AsyncLogWriter and accesses _lock directly.
>> 
>> Thanks,
>> David
>
> PS. If it were warranted, the way to do your "sanity check" would be to introduce a BinarySemaphore class that always initializes to a count of 1. But we do not need this.

I see. I remove the sanity check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From dholmes at openjdk.java.net  Tue Jun 15 06:31:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 06:31:43 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v4]
In-Reply-To: <kd2LxaZevNcXRLidXmNMHw9tdRqwiQwgK3L1NrQaEDU=.f2654b02-4dbf-4ba1-90ef-88fa0541b3ba@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <kd2LxaZevNcXRLidXmNMHw9tdRqwiQwgK3L1NrQaEDU=.f2654b02-4dbf-4ba1-90ef-88fa0541b3ba@github.com>
Message-ID: <y3x7e9Wb2SGLmDr9Ogp27HPXBkdb9lSbnRn0IagKKAw=.15074fdd-801f-419a-a344-69b657f47c49@github.com>

On Tue, 15 Jun 2021 06:19:15 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
>> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
>> 
>> This patch change those to regular data members. This prevents from deleting.
>> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not do sanity check for AsyncLogLocker

src/hotspot/share/logging/logAsyncWriter.cpp line 36:

> 34:  public:
> 35:   AsyncLogLocker(Semaphore* sem): _sem(sem) {
> 36:     _sem->wait();

This class is not general purpose. It does not need to accept an arbitrary semaphore. There is only one semaphore this class works with and that is AsyncLogWriter::_instance->_lock, so it can just use it directly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From xliu at openjdk.java.net  Tue Jun 15 07:24:10 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 15 Jun 2021 07:24:10 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v5]
In-Reply-To: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
Message-ID: <q9fUlcuDZqUDdQWrFE_ST9CrovLUDYQGtq3su3A2Vgc=.8965ebfb-ba53-4daa-b98c-b153e08f6eff@github.com>

> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
> 
> This patch change those to regular data members. This prevents from deleting.
> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Use AsyncLogWriter::_instance->_lock directly.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4479/files
  - new: https://git.openjdk.java.net/jdk/pull/4479/files/e683f30b..12acaca4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4479&range=03-04

  Stats: 12 lines in 2 files changed: 3 ins; 2 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4479/head:pull/4479

PR: https://git.openjdk.java.net/jdk/pull/4479

From xliu at openjdk.java.net  Tue Jun 15 07:24:11 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 15 Jun 2021 07:24:11 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v4]
In-Reply-To: <y3x7e9Wb2SGLmDr9Ogp27HPXBkdb9lSbnRn0IagKKAw=.15074fdd-801f-419a-a344-69b657f47c49@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <kd2LxaZevNcXRLidXmNMHw9tdRqwiQwgK3L1NrQaEDU=.f2654b02-4dbf-4ba1-90ef-88fa0541b3ba@github.com>
 <y3x7e9Wb2SGLmDr9Ogp27HPXBkdb9lSbnRn0IagKKAw=.15074fdd-801f-419a-a344-69b657f47c49@github.com>
Message-ID: <yf4LTnQ0S7Tcs3_L1kRSiwGVMVwKA4SPaX07FTroWLs=.c8158ff9-bad5-4685-b0d8-066eb5ad6314@github.com>

On Tue, 15 Jun 2021 06:28:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not do sanity check for AsyncLogLocker
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 36:
> 
>> 34:  public:
>> 35:   AsyncLogLocker(Semaphore* sem): _sem(sem) {
>> 36:     _sem->wait();
> 
> This class is not general purpose. It does not need to accept an arbitrary semaphore. There is only one semaphore this class works with and that is AsyncLogWriter::_instance->_lock, so it can just use it directly.

Update.  declare AsyncLogLocker as an inner class so we don't need declare it as a friend.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From dholmes at openjdk.java.net  Tue Jun 15 10:22:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 10:22:15 GMT
Subject: [jdk17] RFR: 8260194: Update the documentation for -Xcheck:jni
Message-ID: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>

Please review this update to the -Xcheck:jni description in the java manpage.

For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:

https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html

A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)

Thanks,
David

-------------

Commit messages:
 - Remove java.html again
 - Temporary commit of java.html for ease of reading the changes.
 - 8260194: Update the documentation for -Xcheck:jni

Changes: https://git.openjdk.java.net/jdk17/pull/52/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=52&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260194
  Stats: 68 lines in 1 file changed: 62 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/52/head:pull/52

PR: https://git.openjdk.java.net/jdk17/pull/52

From dholmes at openjdk.java.net  Tue Jun 15 10:23:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 10:23:43 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v5]
In-Reply-To: <q9fUlcuDZqUDdQWrFE_ST9CrovLUDYQGtq3su3A2Vgc=.8965ebfb-ba53-4daa-b98c-b153e08f6eff@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <q9fUlcuDZqUDdQWrFE_ST9CrovLUDYQGtq3su3A2Vgc=.8965ebfb-ba53-4daa-b98c-b153e08f6eff@github.com>
Message-ID: <X5L4Is94yYJGFeVjrPhg4Z-yBU7veHXL0Ko-ILHsL6g=.2d2c788c-eb7f-4593-961b-5cc0dfb812a8@github.com>

On Tue, 15 Jun 2021 07:24:10 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
>> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
>> 
>> This patch change those to regular data members. This prevents from deleting.
>> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use AsyncLogWriter::_instance->_lock directly.

This looks good to me now. Thanks!

David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4479

From david.holmes at oracle.com  Tue Jun 15 12:38:39 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Jun 2021 22:38:39 +1000
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <oc2ls6rqfeStHlw8mx7pzcNBKRjaAUhvV_pF3nAjPas=.c5b1e81d-fdd1-43a5-a42e-6537789aab14@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <8f262b53-2755-b898-4a3a-c35412d42039@oracle.com>
 <oc2ls6rqfeStHlw8mx7pzcNBKRjaAUhvV_pF3nAjPas=.c5b1e81d-fdd1-43a5-a42e-6537789aab14@github.com>
Message-ID: <229ca601-9052-a2cd-8403-d1fbfb39010b@oracle.com>

On 15/06/2021 3:40 pm, Xin Liu wrote:
> On Mon, 14 Jun 2021 22:21:13 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> The updated branch passes the tier6 testing that previously failed. If
> rotate() should not be being used by the test, yet the rotate() fix has
> addressed the crashes, then apparently something else must be happening
> here that is not fully understood.
> 
> Thanks for the feedback. To be honest, I am not sure what the root cause is.
> I ran those two concurrent tests in hours as follows on different platforms, I have never seen a single crash. If I can have a reproducible, I will certainly figure out why and fix it.
> 
> Now I intend to believe it's an external factor which caused it fails.  Those two tests don't trigger log rotation, but other gtests may do. Perhaps Oracle Linux mounts a small partition on /tmp.
> 
> My comment is like "a theory of operation". I try to document the original author's intention.  IMHO, it's thread-safe.
> Do you mind trying that patch again?  Maybe we were just lucky.

This time I got the old crash again in tier7:

[ RUN      ] LogConfigurationTest.reconfigure_decorators_MT_vm
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/opt/mach5/mesos/work_dir/slaves/35546316-ed70-4084-8244-d672e7734fd1-S56997/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/3e3c1142-1595-4682-b00e-27397233f191/runs/5367405b-c511-4cff-962e-c538d3a40ccb/workspace/open/src/hotspot/share/logging/logDecorations.cpp:78), 
pid=23019, tid=23025
#  assert(_decorators.is_decorator(decorator)) failed: decorator was not 
part of the decorator set specified at creation.
#
# JRE version: Java(TM) SE Runtime Environment (18.0) (fastdebug build 
18-internal+0-2021-06-15-0623001.david.holmes.jdk-dev3.git)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 
18-internal+0-2021-06-15-0623001.david.holmes.jdk-dev3.git, mixed mode, 
tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x15fa3e4] 
LogDecorations::decoration(LogDecorators::Decorator, char*, unsigned 
long) const+0x94
#

Stack: [0x00007f8834f2a000,0x00007f883502a000],  sp=0x00007f8835028600, 
  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V  [libjvm.so+0x15fa3e4] 
LogDecorations::decoration(LogDecorators::Decorator, char*, unsigned 
long) const+0x94
V  [libjvm.so+0x15fd207]  LogFileStreamOutput::write(LogDecorations 
const&, char const*)+0x77
V  [libjvm.so+0x15fc4f2]  LogFileOutput::write_blocking(LogDecorations 
const&, char const*)+0x42
V  [libjvm.so+0x15f6b0d]  AsyncLogWriter::run()+0x35d
V  [libjvm.so+0x1c0d0c0]  Thread::call_run()+0x100
V  [libjvm.so+0x18d9f64]  thread_native_entry(Thread*)+0x10


BTW: I noticed a separate bug in the crash log. You've defined:

  bool is_Named_thread() const override { return true; }

for the AsyncLogWriter, but as you pointed out when I asked, this thread 
can't be a NamedThread because that is a special kind of GC thread. So 
that method should not be there.

David
-----

> 
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_MT_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_MT_vm (3601037 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_tags_MT_vm
> [       OK ] LogConfigurationTest.reconfigure_tags_MT_vm (3600112 ms)
> 
> 
> thanks,
> --lx
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4408
> 

From coleenp at openjdk.java.net  Tue Jun 15 14:54:48 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 15 Jun 2021 14:54:48 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading
In-Reply-To: <U20Z6tFeuC--JWe2QIHZuaqu8ot29bHJJg3bcwsc8B0=.ae96f4dd-a5b9-472a-92e0-00b17fb029f3@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
 <U20Z6tFeuC--JWe2QIHZuaqu8ot29bHJJg3bcwsc8B0=.ae96f4dd-a5b9-472a-92e0-00b17fb029f3@github.com>
Message-ID: <wLwWY7Ety5umHOUSBAMPJyqTrR9dNiCG9_SWMST94NQ=.073ea5e3-5ecb-405e-be51-a9e434fe4221@github.com>

On Tue, 15 Jun 2021 03:10:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
>> 
>> Tested with tier1-3 in mach5.
>
> src/hotspot/share/classfile/javaAssertions.cpp line 139:
> 
>> 137:   for (index = len - 1; p != 0; p = p->next(), --index) {
>> 138:     assert(index >= 0, "length does not match list");
>> 139:     TempNewSymbol name = SymbolTable::new_symbol(p->name());
> 
> Why do we need a temp symbol?

Because the new_symbol call will increment the Symbol* refcount in the SymbolTable, it's then copied to the java.lang.String, so the name isn't needed after this.

> src/hotspot/share/classfile/javaClasses.hpp line 231:
> 
>> 229: 
>> 230:   // Conversion between '.' and '/' formats, and allocate a String from the result.
>> 231:   static Handle externalize_classname(Symbol* java_string, TRAPS);
> 
> Nit: java_name might be more apt.

Done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From coleenp at openjdk.java.net  Tue Jun 15 14:59:50 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 15 Jun 2021 14:59:50 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading
In-Reply-To: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
Message-ID: <SDElBYzKg4qKw4qIp5rn_OXlXDPIMVI0Wpj85zJs9Z0=.b47eefbd-7ac4-442d-80a3-272782a28b24@github.com>

On Mon, 24 May 2021 20:24:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
> 
> Tested with tier1-3 in mach5.

Since Symbol* comes from class_name_symbol, it's verified to be valid UTF8 and not unicode, so I believe it's valid to translate '/' to '.' using char conversion.
Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From iklam at openjdk.java.net  Tue Jun 15 18:28:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 15 Jun 2021 18:28:57 GMT
Subject: RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock
Message-ID: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>

Fixing a mistake in https://git.openjdk.java.net/jdk/pull/4322

`SystemDictionaryShared::check_excluded_classes()` iterates over `_dumptime_table`, so we must hold the `DumpTimeTable_lock` first. Otherwise concurrent class unloading may be modifying the `_dumptime_table` while we are still iterating it.

I also removed an outdated comment.

(This fix should be backported to JDK 17, but I want to have some mileage on it in the JDK 18 repo first.)

-------------

Commit messages:
 - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock

Changes: https://git.openjdk.java.net/jdk/pull/4494/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4494&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268778
  Stats: 10 lines in 3 files changed: 5 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4494.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4494/head:pull/4494

PR: https://git.openjdk.java.net/jdk/pull/4494

From hseigel at openjdk.java.net  Tue Jun 15 20:28:09 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 15 Jun 2021 20:28:09 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should not
 be performed
Message-ID: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>

Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".

Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:

If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.

The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8268720: Unspecified checks on NameAndType constants should not be performed

Changes: https://git.openjdk.java.net/jdk/pull/4497/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268720
  Stats: 309 lines in 3 files changed: 300 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4497/head:pull/4497

PR: https://git.openjdk.java.net/jdk/pull/4497

From ccheung at openjdk.java.net  Tue Jun 15 20:37:10 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Jun 2021 20:37:10 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed
Message-ID: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>

This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
It also fixes the non-NULL check at line 88.

- [x] mach5 tiers 1, 2 tests

-------------

Commit messages:
 - 8268078: ClassListParser::_interfaces should be freed

Changes: https://git.openjdk.java.net/jdk/pull/4498/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4498&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268078
  Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4498/head:pull/4498

PR: https://git.openjdk.java.net/jdk/pull/4498

From ccheung at openjdk.java.net  Tue Jun 15 20:40:01 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Jun 2021 20:40:01 GMT
Subject: [jdk17] Integrated: 8268828: ProblemList
 compiler/intrinsics/VectorizedMismatchTest.java on win-x64
In-Reply-To: <MrHWfZaxfo34GKHkH_3HenOMzGH9sPbVuzk4HA3bEfI=.93a56137-a5dd-44d0-8a9b-7bbb6ebf5a72@github.com>
References: <MrHWfZaxfo34GKHkH_3HenOMzGH9sPbVuzk4HA3bEfI=.93a56137-a5dd-44d0-8a9b-7bbb6ebf5a72@github.com>
Message-ID: <jfR9to1nDs3zHB4__ABdLW7uYoEnSEZwCw073jWmW3k=.582d6419-6ba5-44f9-aa5c-d370e7deb32f@github.com>

On Tue, 15 Jun 2021 20:31:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64.

Looks good and trivial.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/64

From dcubed at openjdk.java.net  Tue Jun 15 20:40:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 20:40:00 GMT
Subject: [jdk17] Integrated: 8268828: ProblemList
 compiler/intrinsics/VectorizedMismatchTest.java on win-x64
Message-ID: <MrHWfZaxfo34GKHkH_3HenOMzGH9sPbVuzk4HA3bEfI=.93a56137-a5dd-44d0-8a9b-7bbb6ebf5a72@github.com>

A trivial fix to ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64.

-------------

Commit messages:
 - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64

Changes: https://git.openjdk.java.net/jdk17/pull/64/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=64&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268828
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/64.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/64/head:pull/64

PR: https://git.openjdk.java.net/jdk17/pull/64

From dcubed at openjdk.java.net  Tue Jun 15 20:40:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 20:40:01 GMT
Subject: [jdk17] Integrated: 8268828: ProblemList
 compiler/intrinsics/VectorizedMismatchTest.java on win-x64
In-Reply-To: <jfR9to1nDs3zHB4__ABdLW7uYoEnSEZwCw073jWmW3k=.582d6419-6ba5-44f9-aa5c-d370e7deb32f@github.com>
References: <MrHWfZaxfo34GKHkH_3HenOMzGH9sPbVuzk4HA3bEfI=.93a56137-a5dd-44d0-8a9b-7bbb6ebf5a72@github.com>
 <jfR9to1nDs3zHB4__ABdLW7uYoEnSEZwCw073jWmW3k=.582d6419-6ba5-44f9-aa5c-d370e7deb32f@github.com>
Message-ID: <g0DA_yE82ZnlO9DfbJU533DSIyELcNmSacWrGbJ5fBU=.62472e3d-cb2f-40a0-bcd8-70ff275aac2b@github.com>

On Tue, 15 Jun 2021 20:34:12 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64.
>
> Looks good and trivial.

@calvinccheung - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/64

From dcubed at openjdk.java.net  Tue Jun 15 20:40:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 20:40:02 GMT
Subject: [jdk17] Integrated: 8268828: ProblemList
 compiler/intrinsics/VectorizedMismatchTest.java on win-x64
In-Reply-To: <MrHWfZaxfo34GKHkH_3HenOMzGH9sPbVuzk4HA3bEfI=.93a56137-a5dd-44d0-8a9b-7bbb6ebf5a72@github.com>
References: <MrHWfZaxfo34GKHkH_3HenOMzGH9sPbVuzk4HA3bEfI=.93a56137-a5dd-44d0-8a9b-7bbb6ebf5a72@github.com>
Message-ID: <QQGaiAtzlYhn8M-wNdlaJ8Ei2toEXs1_gS0IjwDSNYA=.15c9c445-802f-4c51-8afb-ce265d653c02@github.com>

On Tue, 15 Jun 2021 20:31:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64.

This pull request has now been integrated.

Changeset: 9ac0609e
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/9ac0609ed1513a5c7484ccc2c219fe6cd9c9d6d6
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk17/pull/64

From ccheung at openjdk.java.net  Tue Jun 15 20:46:46 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Jun 2021 20:46:46 GMT
Subject: RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock
In-Reply-To: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
References: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
Message-ID: <3zfFnUHkvy-Y6_I-7a5duHXbDRlDdeYDByeZPWWfM28=.18ed89e3-6e24-4184-8d4f-3a4f8f97ce4f@github.com>

On Tue, 15 Jun 2021 17:07:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fixing a mistake in https://git.openjdk.java.net/jdk/pull/4322
> 
> `SystemDictionaryShared::check_excluded_classes()` iterates over `_dumptime_table`, so we must hold the `DumpTimeTable_lock` first. Otherwise concurrent class unloading may be modifying the `_dumptime_table` while we are still iterating it.
> 
> I also removed an outdated comment.
> 
> (This fix should be backported to JDK 17, but I want to have some mileage on it in the JDK 18 repo first.)

LGTM.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4494

From kbarrett at openjdk.java.net  Tue Jun 15 21:52:00 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 15 Jun 2021 21:52:00 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
In-Reply-To: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
References: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
Message-ID: <Zd8aOXl5c2yQGhNrIM8wV06yVx9eGhJAB7uAoGmY2C8=.69e77951-9def-409e-8dd7-6b93ed6989bd@github.com>

On Tue, 15 Jun 2021 21:38:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.

Changes requested by kbarrett (Reviewer).

Looks good.

test/hotspot/jtreg/ProblemList-zgc.txt line 46:

> 44: serviceability/dcmd/framework/HelpTest.java                   8268433 windows-x64
> 45: serviceability/dcmd/framework/InvalidCommandTest.java         8268433 windows-x6
> 46: 4

"4" on it's own line x 2

-------------

PR: https://git.openjdk.java.net/jdk17/pull/66Marked as reviewed by kbarrett (Reviewer).

From dcubed at openjdk.java.net  Tue Jun 15 21:52:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 21:52:00 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
Message-ID: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>

A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.

-------------

Commit messages:
 - Fix broken lines in new entries.
 - 8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64

Changes: https://git.openjdk.java.net/jdk17/pull/66/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=66&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268830
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/66.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/66/head:pull/66

PR: https://git.openjdk.java.net/jdk17/pull/66

From dcubed at openjdk.java.net  Tue Jun 15 21:52:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 21:52:00 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
In-Reply-To: <Zd8aOXl5c2yQGhNrIM8wV06yVx9eGhJAB7uAoGmY2C8=.69e77951-9def-409e-8dd7-6b93ed6989bd@github.com>
References: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
 <Zd8aOXl5c2yQGhNrIM8wV06yVx9eGhJAB7uAoGmY2C8=.69e77951-9def-409e-8dd7-6b93ed6989bd@github.com>
Message-ID: <0MxgjXppM4IkFEWHRsw5ODPpMt3TeGFz5svrUFsJ_zo=.87ff3e84-f4a1-4d1d-b86f-1da7dd63e5b0@github.com>

On Tue, 15 Jun 2021 21:41:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.
>
> Changes requested by kbarrett (Reviewer).

@kimbarrett - Thanks for catching that! Made my terminal wider... :-)
Fixed.

> Looks good.

@kimbarrett - Thanks for both reviews!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/66

From dcubed at openjdk.java.net  Tue Jun 15 21:52:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 21:52:01 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
In-Reply-To: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
References: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
Message-ID: <yj00v84b9kJeIlu0EkYQyMrAeoEO3a_m5CFOTJonJDM=.d28d4e51-13d2-48f0-a729-36dd67c81b5c@github.com>

On Tue, 15 Jun 2021 21:38:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.

This pull request has now been integrated.

Changeset: 10068c1b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/10068c1bace0ea650bda3e2234a44cbf401afc7d
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.java.net/jdk17/pull/66

From minqi at openjdk.java.net  Tue Jun 15 22:14:33 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 15 Jun 2021 22:14:33 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed
In-Reply-To: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
Message-ID: <ZxYyWjh1hZ6vx0Aw1JYTLZpLtXYz1j8E5JJCoke4uwg=.93c28c6e-5629-4ac4-9789-19b8af4dbfc6@github.com>

On Tue, 15 Jun 2021 20:29:12 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
> It also fixes the non-NULL check at line 88.
> 
> - [x] mach5 tiers 1, 2 tests

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4498

From iklam at openjdk.java.net  Tue Jun 15 22:28:36 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 15 Jun 2021 22:28:36 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed
In-Reply-To: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
Message-ID: <V8eQa6aSrirvFJF6whwinyPp6Axj7HqIjn_xa_MAzJ4=.97a7a0b1-d0e0-4d72-9486-321d1d965eb0@github.com>

On Tue, 15 Jun 2021 20:29:12 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
> It also fixes the non-NULL check at line 88.
> 
> - [x] mach5 tiers 1, 2 tests

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/classListParser.cpp line 94:

> 92:   delete _indy_items;
> 93:   delete _interfaces;
> 94:   cleanup_table();

I just realized that the `_id2klass_table` contains only `InstanceKlass*` values, so there's no need to clean up the values themselves (the InstanceKlass should keep on living after the table is deallocated).

It's the entries of `_id2klass_table` that need to be freed, but that should be done separately. See [JDK-8267752](https://bugs.openjdk.java.net/browse/JDK-8267752)

So I think the changes related to `_id2klass_table` in this PR are no longer needed. Sorry for pointing you to the wrong direction. The rest looks OK to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4498

From coleenp at openjdk.java.net  Tue Jun 15 22:33:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 15 Jun 2021 22:33:32 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed
In-Reply-To: <V8eQa6aSrirvFJF6whwinyPp6Axj7HqIjn_xa_MAzJ4=.97a7a0b1-d0e0-4d72-9486-321d1d965eb0@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
 <V8eQa6aSrirvFJF6whwinyPp6Axj7HqIjn_xa_MAzJ4=.97a7a0b1-d0e0-4d72-9486-321d1d965eb0@github.com>
Message-ID: <IyL6KJBV3uyMmZdyfp-uXpm2DMT3jiFv6JrAuGQcQqY=.f4688618-259b-4877-a095-a91d6f69db7b@github.com>

On Tue, 15 Jun 2021 22:25:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
>> It also fixes the non-NULL check at line 88.
>> 
>> - [x] mach5 tiers 1, 2 tests
>
> src/hotspot/share/cds/classListParser.cpp line 94:
> 
>> 92:   delete _indy_items;
>> 93:   delete _interfaces;
>> 94:   cleanup_table();
> 
> I just realized that the `_id2klass_table` contains only `InstanceKlass*` values, so there's no need to clean up the values themselves (the InstanceKlass should keep on living after the table is deallocated).
> 
> It's the entries of `_id2klass_table` that need to be freed, but that should be done separately. See [JDK-8267752](https://bugs.openjdk.java.net/browse/JDK-8267752)
> 
> So I think the changes related to `_id2klass_table` in this PR are no longer needed. Sorry for pointing you to the wrong direction. The rest looks OK to me.

Yes, I have a PR for JDK-8267752.  The release_C_heap_structures shouldn't be called until the classes are either unloaded or deallocated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4498

From mseledtsov at openjdk.java.net  Tue Jun 15 22:45:34 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 22:45:34 GMT
Subject: [jdk17] RFR: 8268594: runtime/handshake tests don't need WhiteBox
 after AOT removal
In-Reply-To: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
References: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
Message-ID: <6a_InOaBL9Kl9aed_3nREIpkOHVPUOV9SDdPR1rU2y8=.d5f749ef-e299-4926-848f-e2e3c418965b@github.com>

On Fri, 11 Jun 2021 08:45:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> `runtime/handshake/HandshakeTransitionTest.java` and `HandshakeTimeoutTest.java` use WhiteBox to check the value of `UseJVMCICompiler` as a workaround for AOT not supporting local handshakes (see [JDK-8191437](https://bugs.openjdk.java.net/browse/JDK-8191437)). 
>>
>> this isn't needed anymore and can be removed.
> 
> testing: `runtime/handshake` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Looks good

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/19

From ccheung at openjdk.java.net  Tue Jun 15 22:47:54 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Jun 2021 22:47:54 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed [v2]
In-Reply-To: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
Message-ID: <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>

> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
> It also fixes the non-NULL check at line 88.
> 
> - [x] mach5 tiers 1, 2 tests

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  revert the changes for freeing the _id2klass_table

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4498/files
  - new: https://git.openjdk.java.net/jdk/pull/4498/files/58f7c03e..903c9380

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4498&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4498&range=00-01

  Stats: 16 lines in 2 files changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4498/head:pull/4498

PR: https://git.openjdk.java.net/jdk/pull/4498

From mseledtsov at openjdk.java.net  Tue Jun 15 22:49:33 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 22:49:33 GMT
Subject: [jdk17] RFR: 8268599: mark hotspot runtime/sealedClasses tests
 which ignore external VM flags
In-Reply-To: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
References: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
Message-ID: <jyOvxmnAbBrxfapuJe74z8fEGonznW3XdBz92grPOAk=.77f4a1cd-616b-427b-8bca-7d7862741abe@github.com>

On Fri, 11 Jun 2021 09:36:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `runtime/sealedClasses` tests which ignore all external flags?
> 
> Thanks,
> -- Igor

Looks good

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/23

From ccheung at openjdk.java.net  Tue Jun 15 22:50:37 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Jun 2021 22:50:37 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed [v2]
In-Reply-To: <IyL6KJBV3uyMmZdyfp-uXpm2DMT3jiFv6JrAuGQcQqY=.f4688618-259b-4877-a095-a91d6f69db7b@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
 <V8eQa6aSrirvFJF6whwinyPp6Axj7HqIjn_xa_MAzJ4=.97a7a0b1-d0e0-4d72-9486-321d1d965eb0@github.com>
 <IyL6KJBV3uyMmZdyfp-uXpm2DMT3jiFv6JrAuGQcQqY=.f4688618-259b-4877-a095-a91d6f69db7b@github.com>
Message-ID: <XYSdfbvuD0E0yV0nO2MakOcxwQF8vxjYGa7EAsgeg6w=.6164e70c-46f7-4cfb-8681-8e5331ee165e@github.com>

On Tue, 15 Jun 2021 22:29:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/cds/classListParser.cpp line 94:
>> 
>>> 92:   delete _indy_items;
>>> 93:   delete _interfaces;
>>> 94:   cleanup_table();
>> 
>> I just realized that the `_id2klass_table` contains only `InstanceKlass*` values, so there's no need to clean up the values themselves (the InstanceKlass should keep on living after the table is deallocated).
>> 
>> It's the entries of `_id2klass_table` that need to be freed, but that should be done separately. See [JDK-8267752](https://bugs.openjdk.java.net/browse/JDK-8267752)
>> 
>> So I think the changes related to `_id2klass_table` in this PR are no longer needed. Sorry for pointing you to the wrong direction. The rest looks OK to me.
>
> Yes, I have a PR for JDK-8267752.  The release_C_heap_structures shouldn't be called until the classes are either unloaded or deallocated.

Ioi, Coleen, Yumin, thanks for the review.
I've reverted the changes related to `_id2klass_table`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4498

From mseledtsov at openjdk.java.net  Tue Jun 15 22:51:30 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 22:51:30 GMT
Subject: [jdk17] RFR: 8268598: mark hotspot runtime/stringtable tests
 which ignore external VM flags
In-Reply-To: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
References: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
Message-ID: <iXtl6BquomHUZV8T4mkD0LjIuBZNXfBYoSIyb3J5nu8=.e28e2946-76a6-46c8-809d-ea7a697a95c8@github.com>

On Fri, 11 Jun 2021 09:17:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `stringtable/StringTableVerifyTest.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

LGTM

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/22

From mseledtsov at openjdk.java.net  Tue Jun 15 22:52:35 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 22:52:35 GMT
Subject: [jdk17] RFR: 8268597: mark hotspot runtime/symboltable tests
 which ignore external VM flags
In-Reply-To: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
References: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
Message-ID: <hcd2qrQUEvHS9x8Kynlu5-GUrvPYBGROOpGcwvOBlKw=.22f67674-cb7f-4fd8-93b3-2e61a3dbc191@github.com>

On Fri, 11 Jun 2021 09:13:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `symboltable/ShortLivedSymbolCleanup.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

LGTM

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/21

From mseledtsov at openjdk.java.net  Tue Jun 15 22:52:47 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 22:52:47 GMT
Subject: [jdk17] RFR: 8268596: mark hotspot runtime/verifier tests which
 ignore external VM flags
In-Reply-To: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
References: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
Message-ID: <G2XEKLqI0nw7_fdJiHgwazs9-S85Ey9qaY5rTqlx2Us=.bc1f8d9b-b813-4809-9984-bcf342f707e1@github.com>

On Fri, 11 Jun 2021 09:09:14 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `verifier/TraceClassRes.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Looks good to me.

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/20

From mseledtsov at openjdk.java.net  Tue Jun 15 22:53:38 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 22:53:38 GMT
Subject: [jdk17] RFR: 8268601: mark hotspot runtime/records tests which
 ignore external VM flags
In-Reply-To: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
References: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
Message-ID: <QL9klsgwECzGCk6biBpRKtT7_IEyPwbaVFtrSJF-l_I=.5318f6b5-bf3c-4fb6-81fc-eb36ceb38456@github.com>

On Fri, 11 Jun 2021 09:43:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `RedefineRecord.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Looks good to me

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/24

From coleenp at openjdk.java.net  Tue Jun 15 22:57:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 15 Jun 2021 22:57:37 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed [v2]
In-Reply-To: <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
 <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
Message-ID: <vkBHh-NbGWHnXSMIzx66ZDm0v-ZAn_xELFJbGGIdTA8=.6a401266-c6d1-4b85-abd6-3976a5f3112a@github.com>

On Tue, 15 Jun 2021 22:47:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
>> It also fixes the non-NULL check at line 88.
>> 
>> - [x] mach5 tiers 1, 2 tests
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the changes for freeing the _id2klass_table

Looks good to me!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4498

From mseledtsov at openjdk.java.net  Tue Jun 15 23:00:33 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 15 Jun 2021 23:00:33 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
Message-ID: <6tbe2Dl6uwdAlatkomaNOVEipnDDxh1RMV8oeQXbj10=.db751893-7820-4d17-8521-514bb3447097@github.com>

On Fri, 11 Jun 2021 08:31:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that removes `/othervm` from 3 `runtime/jni` tests?
> from JBS:
>> `runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java`, `checked/TestCheckedEnsureLocalCapacity.java`, and `atExit/TestAtExit.java` use `main/othervm` whereas in fact, they don't need `othervm`, and if we had CODETOOLS-7902658 implemented, they would have used `driver` mode. this RFE is to remove `/othervm`, so we at least won't waste time on creating a fresh JVM.
> 
> the patch explicitly sets `-Djava.library.path=` for the child processes so they are able to locate native libraries.
> 
> testing: `runtime/jni` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Looks reasonable to me.

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/18

From minqi at openjdk.java.net  Tue Jun 15 23:39:30 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 15 Jun 2021 23:39:30 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed [v2]
In-Reply-To: <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
 <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
Message-ID: <qy5uCFNYAUstM_E_PfRAPMn5STSZg5GCdBaW0ONGRcc=.7fed989d-0967-456f-96bd-34be732b4abf@github.com>

On Tue, 15 Jun 2021 22:47:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
>> It also fixes the non-NULL check at line 88.
>> 
>> - [x] mach5 tiers 1, 2 tests
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the changes for freeing the _id2klass_table

src/hotspot/share/cds/classListParser.cpp line 93:

> 91:   Atomic::store(&_parsing_thread, (Thread*)NULL);
> 92:   delete _indy_items;
> 93:   delete _interfaces;

In fact below _instance = NULL is not necessary. ClassListParser is a stack object and in ctor, it sets 
_instance = this;
So after ClassListParser deallocated from stack, setting it to NULL makes no sense.
If it is heap object, setting it to NULL could not prevent memory leak.
Should we remove it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4498

From dcubed at openjdk.java.net  Tue Jun 15 23:53:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 23:53:45 GMT
Subject: [jdk17] Integrated: 8268851: ProblemList
 jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64
Message-ID: <fzNnH_PTd0PaP3WcWvV_SUF9RaH3FrJIKk1ANkXcO1I=.09347e11-5f8a-4f1b-8e6b-436ecc246120@github.com>

A trivial fix to ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64.

-------------

Commit messages:
 - 8268851: ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64

Changes: https://git.openjdk.java.net/jdk17/pull/70/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=70&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268851
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/70.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/70/head:pull/70

PR: https://git.openjdk.java.net/jdk17/pull/70

From bpb at openjdk.java.net  Tue Jun 15 23:53:46 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 15 Jun 2021 23:53:46 GMT
Subject: [jdk17] Integrated: 8268851: ProblemList
 jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64
In-Reply-To: <fzNnH_PTd0PaP3WcWvV_SUF9RaH3FrJIKk1ANkXcO1I=.09347e11-5f8a-4f1b-8e6b-436ecc246120@github.com>
References: <fzNnH_PTd0PaP3WcWvV_SUF9RaH3FrJIKk1ANkXcO1I=.09347e11-5f8a-4f1b-8e6b-436ecc246120@github.com>
Message-ID: <-ao1DIM9OLWDKVd4_fCEtYILmc-ZDl32tLUAIcpe7Fo=.cc32bbe8-a24e-4548-9d32-bc5eb2493631@github.com>

On Tue, 15 Jun 2021 23:45:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/70

From dcubed at openjdk.java.net  Tue Jun 15 23:53:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 23:53:46 GMT
Subject: [jdk17] Integrated: 8268851: ProblemList
 jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64
In-Reply-To: <-ao1DIM9OLWDKVd4_fCEtYILmc-ZDl32tLUAIcpe7Fo=.cc32bbe8-a24e-4548-9d32-bc5eb2493631@github.com>
References: <fzNnH_PTd0PaP3WcWvV_SUF9RaH3FrJIKk1ANkXcO1I=.09347e11-5f8a-4f1b-8e6b-436ecc246120@github.com>
 <-ao1DIM9OLWDKVd4_fCEtYILmc-ZDl32tLUAIcpe7Fo=.cc32bbe8-a24e-4548-9d32-bc5eb2493631@github.com>
Message-ID: <RaBZ-l3IwPJKedY_vd9PmzrTsUyRAhQokUIsj1XI34o=.a72f4549-8d65-4358-b543-fb32096aeab6@github.com>

On Tue, 15 Jun 2021 23:47:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/70

From dcubed at openjdk.java.net  Tue Jun 15 23:53:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 23:53:46 GMT
Subject: [jdk17] Integrated: 8268851: ProblemList
 jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64
In-Reply-To: <fzNnH_PTd0PaP3WcWvV_SUF9RaH3FrJIKk1ANkXcO1I=.09347e11-5f8a-4f1b-8e6b-436ecc246120@github.com>
References: <fzNnH_PTd0PaP3WcWvV_SUF9RaH3FrJIKk1ANkXcO1I=.09347e11-5f8a-4f1b-8e6b-436ecc246120@github.com>
Message-ID: <2msR7MkkAbfAIXmq8daU6pqqpKeHbb4BVc5FiJeJ2Uk=.b54a8d43-45f6-479b-9bc2-666c3cba0b03@github.com>

On Tue, 15 Jun 2021 23:45:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64.

This pull request has now been integrated.

Changeset: b18de6cf
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/b18de6cf79e0195736d94b08be67f10ca7c3cd08
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268851: ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk17/pull/70

From minqi at openjdk.java.net  Tue Jun 15 23:56:33 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 15 Jun 2021 23:56:33 GMT
Subject: RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock
In-Reply-To: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
References: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
Message-ID: <fuqyPwQwAS0jyy1oyRhRbRhZ9OTO-sVbIprPU2JFmq4=.e905d71e-2603-410a-8b7f-76e52973a900@github.com>

On Tue, 15 Jun 2021 17:07:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fixing a mistake in https://git.openjdk.java.net/jdk/pull/4322
> 
> `SystemDictionaryShared::check_excluded_classes()` iterates over `_dumptime_table`, so we must hold the `DumpTimeTable_lock` first. Otherwise concurrent class unloading may be modifying the `_dumptime_table` while we are still iterating it.
> 
> I also removed an outdated comment.
> 
> (This fix should be backported to JDK 17, but I want to have some mileage on it in the JDK 18 repo first.)

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4494

From xliu at openjdk.java.net  Wed Jun 16 00:19:33 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Jun 2021 00:19:33 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <229ca601-9052-a2cd-8403-d1fbfb39010b@oracle.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <229ca601-9052-a2cd-8403-d1fbfb39010b@oracle.com>
Message-ID: <VogOOcv6n6pYNs0fC2I4DA3nUuzc3jIBtfCeaqG-mmg=.42a4ef78-6799-49c9-9982-5b2af0643fcc@github.com>

On Tue, 15 Jun 2021 12:40:18 GMT, David Holmes <david.holmes at oracle.com> wrote:

> for the AsyncLogWriter, but as you pointed out when I asked, this thread
can't be a NamedThread because that is a special kind of GC thread. So
that method should not be there.

Here is original answer: "NamedThread() is not just NonJavaThread with a name.  It has some gc-specific fields. it seams NamedThread is for GC threads. Further, I don't need to support dynamic names."

Yes, you're right. Sidetrack it here JDK-8268852. 
I misinterpret the member function is_Named_Thread().

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From sviswanathan at openjdk.java.net  Wed Jun 16 00:20:32 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 16 Jun 2021 00:20:32 GMT
Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in
 jdk image
In-Reply-To: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
References: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
Message-ID: <sLJIJEBRRS3dDas_nQOupL1WFSgLqpQV2EF3O3OaGb8=.a80da3a4-d2ac-4c84-a59e-e419f28c762c@github.com>

On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/47

From coleenp at openjdk.java.net  Wed Jun 16 00:47:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 00:47:32 GMT
Subject: [jdk17] RFR: 8260194: Update the documentation for -Xcheck:jni
In-Reply-To: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
References: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
Message-ID: <6dcBvEsCm5-MsbDz6BNK0twYhoBZh0YaOxkqcORxk3s=.bd35fd73-6592-4409-9699-28eb5bf4a13b@github.com>

On Tue, 15 Jun 2021 10:09:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this update to the -Xcheck:jni description in the java manpage.
> 
> For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:
> 
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
> 
> A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)
> 
> Thanks,
> David

Looks good.  Just a question:

"A jFieldID, or jMethodID, is detected as being invalid. For example:"

Is this the casing of these used in JNI?

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/52

From minqi at openjdk.java.net  Wed Jun 16 00:49:37 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 16 Jun 2021 00:49:37 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed [v2]
In-Reply-To: <qy5uCFNYAUstM_E_PfRAPMn5STSZg5GCdBaW0ONGRcc=.7fed989d-0967-456f-96bd-34be732b4abf@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
 <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
 <qy5uCFNYAUstM_E_PfRAPMn5STSZg5GCdBaW0ONGRcc=.7fed989d-0967-456f-96bd-34be732b4abf@github.com>
Message-ID: <sZnbdVLQw7LSg5Hot7RXzzHREHKF214SywffjrO4oeo=.47240bef-4569-4552-9653-5ed502d961d5@github.com>

On Tue, 15 Jun 2021 23:36:15 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert the changes for freeing the _id2klass_table
>
> src/hotspot/share/cds/classListParser.cpp line 93:
> 
>> 91:   Atomic::store(&_parsing_thread, (Thread*)NULL);
>> 92:   delete _indy_items;
>> 93:   delete _interfaces;
> 
> In fact below _instance = NULL is not necessary. ClassListParser is a stack object and in ctor, it sets 
> _instance = this;
> So after ClassListParser deallocated from stack, setting it to NULL makes no sense.
> If it is heap object, setting it to NULL could not prevent memory leak.
> Should we remove it?

You can ignore my comment here, It is still useful to set it to NULL:
  static ClassListParser* instance() {
    assert(is_parsing_thread(), "call this only in the thread that created ClassListParsing::_instance");
    assert(_instance != NULL, "must be");
    return _instance;
  }
The static function will check if it is NULL.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4498

From coleenp at openjdk.java.net  Wed Jun 16 00:52:11 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 00:52:11 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v2]
In-Reply-To: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
Message-ID: <aKOMoq3yS0Hyye2qSFaSVgm4h3hAV_IQdiM3XSXA85U=.6cb054a4-3d8d-403b-b619-e0bd62348997@github.com>

> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
> 
> Tested with tier1-3 in mach5.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Changed name of parameter, some nearby indentation.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4173/files
  - new: https://git.openjdk.java.net/jdk/pull/4173/files/00cd12f0..afbffd45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4173&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4173&range=00-01

  Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4173/head:pull/4173

PR: https://git.openjdk.java.net/jdk/pull/4173

From iklam at openjdk.java.net  Wed Jun 16 01:15:31 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 16 Jun 2021 01:15:31 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v2]
In-Reply-To: <aKOMoq3yS0Hyye2qSFaSVgm4h3hAV_IQdiM3XSXA85U=.6cb054a4-3d8d-403b-b619-e0bd62348997@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
 <aKOMoq3yS0Hyye2qSFaSVgm4h3hAV_IQdiM3XSXA85U=.6cb054a4-3d8d-403b-b619-e0bd62348997@github.com>
Message-ID: <zthl8jcguPpa0Nnn7rRbWHj_bhAoO8br4_jM8XLG4iE=.0db4afe2-e814-4089-99a1-137247fb8e6f@github.com>

On Wed, 16 Jun 2021 00:52:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
>> 
>> Tested with tier1-3 in mach5.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed name of parameter, some nearby indentation.

Looks good to me. I check the code paths and they seem to be equivalent to the existing code. A small nit with CHECK_NULL.

src/hotspot/share/classfile/systemDictionary.cpp line 1313:

> 1311: 
> 1312:     // Translate to external class name format, i.e., convert '/' chars to '.'
> 1313:     Handle string = java_lang_String::externalize_classname(class_name, THREAD);

Should this be CHECK_NULL?

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4173

From iklam at openjdk.java.net  Wed Jun 16 01:16:31 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 16 Jun 2021 01:16:31 GMT
Subject: RFR: 8268078: ClassListParser::_interfaces should be freed [v2]
In-Reply-To: <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
 <f0eZV0Y6gpNL3pJxB7gGo0UvBAC6gdSd1kWKlB3YlB4=.22b4db78-2e08-43bb-a572-15be8359a7c1@github.com>
Message-ID: <fPp4331RPDgRyfkaBpJYrVovEO2sicoNm6C0Viwbye4=.f67718d2-62f5-4c95-a620-ad8875af789f@github.com>

On Tue, 15 Jun 2021 22:47:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
>> It also fixes the non-NULL check at line 88.
>> 
>> - [x] mach5 tiers 1, 2 tests
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the changes for freeing the _id2klass_table

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4498

From dholmes at openjdk.java.net  Wed Jun 16 01:20:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 01:20:31 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed
In-Reply-To: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
Message-ID: <Vakhi9kYZMUQIb0q6-2TbNwMcBp93Vtl7yRsJqREUCw=.dba73ffc-590c-4274-83a8-7a5927111066@github.com>

On Tue, 15 Jun 2021 20:17:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
> 
> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
> 
> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
> 
> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
> 
> Thanks, Harold

Hi Harold,

Looks good. A couple of suggested changes to comments.

Thanks,
David

src/hotspot/share/classfile/classFileParser.cpp line 714:

> 712:             } else if (!Signature::is_void_method(signature)) { // must have void return
> 713:               throwIllegalSignature("Method", name, signature, CHECK);
> 714:               return;

So this is the check that is now skipped when doing the NameAndType_info check. In which case the comment should be expanded to something like:

" ... it must be <init\> and must have a void signature"

also the comment at line 697:

// Method name and signature are verified above, when iterating NameAndType_info.

may no longer be accurate.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4497

From jiefu at openjdk.java.net  Wed Jun 16 01:23:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Jun 2021 01:23:38 GMT
Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in
 jdk image
In-Reply-To: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
References: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
Message-ID: <jTSJI4jiBPG3H44OEZov8NIe4yA-PPEN6dfa6zhupl8=.4f07b06a-a4cc-43dc-a185-3ccdc0fac685@github.com>

On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

The test logic should be changed.

If C2 is absent, libsvml.so would not be generated after JDK-8268643.
Thanks.

-------------

Changes requested by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/47

From xliu at openjdk.java.net  Wed Jun 16 01:27:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Jun 2021 01:27:40 GMT
Subject: RFR: 8268852: AsyncLogWriter should not overide is_Named_thread()
Message-ID: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>

AsyncLogWriter is a subclass of NonJavaThread but not NamedThread. Therefore, 
is_Named_thread() must not return true.

Testing: 

1. hardcrash scenario:
...
Other Threads:
  0x00007f2870391f70 VMThread "VM Thread" [stack: 0x00007f2809d7d000,0x00007f2809e7d000] [id=76015]
  0x00007f28706a1d70 WatcherThread [stack: 0x00007f28082f0000,0x00007f28083f0000] [id=76033]
  0x00007f28702499b0 AsyncLog Thread [stack: 0x00007f2809e7f000,0x00007f2809f7f000] [id=76014]
...

2. jcmd $pid Thread.print
...
"AsyncLog Thread" os_prio=0 cpu=1015.24ms elapsed=181.04s tid=0x00007f7b14c57fb0 nid=0x12ed8 runnable
...

-------------

Commit messages:
 - 8268852: AsyncLogWriter should not overide is_Named_thread()

Changes: https://git.openjdk.java.net/jdk/pull/4503/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4503&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268852
  Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4503.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4503/head:pull/4503

PR: https://git.openjdk.java.net/jdk/pull/4503

From dholmes at openjdk.java.net  Wed Jun 16 01:32:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 01:32:53 GMT
Subject: [jdk17] RFR: 8260194: Update the documentation for -Xcheck:jni
 [v2]
In-Reply-To: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
References: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
Message-ID: <bHS2FaA6AK2LmaV5BIsyTmli89bn6RND-tnitjVmK30=.90c027b0-3107-47e2-9f24-6e0d4ca6e062@github.com>

> Please review this update to the -Xcheck:jni description in the java manpage.
> 
> For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:
> 
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
> 
> A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix name case in jfieldID and jmethodID

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/52/files
  - new: https://git.openjdk.java.net/jdk17/pull/52/files/7031dc97..bf28b057

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=52&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=52&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/52/head:pull/52

PR: https://git.openjdk.java.net/jdk17/pull/52

From dholmes at openjdk.java.net  Wed Jun 16 01:32:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 01:32:53 GMT
Subject: [jdk17] RFR: 8260194: Update the documentation for -Xcheck:jni
In-Reply-To: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
References: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
Message-ID: <F4LpIasvc4XKNHPncZ-vgHpm3r3JgjMBLdp13GEDoMg=.31fb10cd-b4c7-4343-a497-c8f9852b9fb1@github.com>

On Tue, 15 Jun 2021 10:09:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this update to the -Xcheck:jni description in the java manpage.
> 
> For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:
> 
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
> 
> A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)
> 
> Thanks,
> David

Thanks for the review Coleen!

Good catch on the incorrect case for jfieldID and jmethodID - now fixed.

David

-------------

PR: https://git.openjdk.java.net/jdk17/pull/52

From ccheung at openjdk.java.net  Wed Jun 16 02:20:36 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 16 Jun 2021 02:20:36 GMT
Subject: Integrated: 8268078: ClassListParser::_interfaces should be freed
In-Reply-To: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
References: <OkRMebrR-s7wSMV02G80KhInornVU7sN8KT5ORW852I=.15984fb1-e6d7-4584-95eb-549343cb79d3@github.com>
Message-ID: <T3aD5AHCedq1qjUxJgQNv3X8L81KIeFfUV9sRrCfZs8=.d9640687-75c5-44c5-862e-6df6b435fb31@github.com>

On Tue, 15 Jun 2021 20:29:12 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This patch frees the `_interfaces`, `_indy_items`, and `_id2klass_table` of `ClassListParser` in its destructor.
> It also fixes the non-NULL check at line 88.
> 
> - [x] mach5 tiers 1, 2 tests

This pull request has now been integrated.

Changeset: 3ad65867
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3ad658677b1ad2ea15d75ec7f1fe71e37f3913b9
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8268078: ClassListParser::_interfaces should be freed

Reviewed-by: minqi, iklam, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/4498

From coleenp at openjdk.java.net  Wed Jun 16 02:25:55 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 02:25:55 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v3]
In-Reply-To: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
Message-ID: <p9nwl_Oe8ehmdkjgNSymYIyCUrbUG_yA4Z-f4grrMeM=.2aab7342-0a57-4b6a-a7a6-b8a3a0b9108d@github.com>

> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
> 
> Tested with tier1-3 in mach5.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix CHECK_NULL.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4173/files
  - new: https://git.openjdk.java.net/jdk/pull/4173/files/afbffd45..d4ec0270

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4173&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4173&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4173/head:pull/4173

PR: https://git.openjdk.java.net/jdk/pull/4173

From coleenp at openjdk.java.net  Wed Jun 16 02:25:56 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 02:25:56 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v3]
In-Reply-To: <zthl8jcguPpa0Nnn7rRbWHj_bhAoO8br4_jM8XLG4iE=.0db4afe2-e814-4089-99a1-137247fb8e6f@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
 <aKOMoq3yS0Hyye2qSFaSVgm4h3hAV_IQdiM3XSXA85U=.6cb054a4-3d8d-403b-b619-e0bd62348997@github.com>
 <zthl8jcguPpa0Nnn7rRbWHj_bhAoO8br4_jM8XLG4iE=.0db4afe2-e814-4089-99a1-137247fb8e6f@github.com>
Message-ID: <2p6hoUTQYCOxqmgpAcgRcC6RxDo9vMAS9WR-IFTUVSY=.6d5d83a8-47e3-45f0-a200-3f5d882385fd@github.com>

On Tue, 15 Jun 2021 22:41:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix CHECK_NULL.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1313:
> 
>> 1311: 
>> 1312:     // Translate to external class name format, i.e., convert '/' chars to '.'
>> 1313:     Handle string = java_lang_String::externalize_classname(class_name, THREAD);
> 
> Should this be CHECK_NULL?

Yes, you're right.  I had some extra logging there at one point in this change history.  Thanks for finding that!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From dholmes at openjdk.java.net  Wed Jun 16 02:28:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 02:28:34 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v3]
In-Reply-To: <wLwWY7Ety5umHOUSBAMPJyqTrR9dNiCG9_SWMST94NQ=.073ea5e3-5ecb-405e-be51-a9e434fe4221@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
 <U20Z6tFeuC--JWe2QIHZuaqu8ot29bHJJg3bcwsc8B0=.ae96f4dd-a5b9-472a-92e0-00b17fb029f3@github.com>
 <wLwWY7Ety5umHOUSBAMPJyqTrR9dNiCG9_SWMST94NQ=.073ea5e3-5ecb-405e-be51-a9e434fe4221@github.com>
Message-ID: <I9Ve6zqAzn7Qkru-s884Kv4jNU2sOQWmE1YlLaY44Jo=.62afc806-a773-4d6d-909d-b3ec23e06d9e@github.com>

On Tue, 15 Jun 2021 14:51:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaAssertions.cpp line 139:
>> 
>>> 137:   for (index = len - 1; p != 0; p = p->next(), --index) {
>>> 138:     assert(index >= 0, "length does not match list");
>>> 139:     TempNewSymbol name = SymbolTable::new_symbol(p->name());
>> 
>> Why do we need a temp symbol?
>
> Because the new_symbol call will increment the Symbol* refcount in the SymbolTable, it's then copied to the java.lang.String, so the name isn't needed after this.

Ah I see. The types were confusing me. We start with a char* convert to a Symbol, then convert that back to char* but with the externalized format. The irony there being that  it seems these Options start in external format but then get stored in internal format!
No issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From dholmes at openjdk.java.net  Wed Jun 16 02:50:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 02:50:32 GMT
Subject: RFR: 8268852: AsyncLogWriter should not overide is_Named_thread()
In-Reply-To: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
References: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
Message-ID: <_pP0Vn_sC8dh2HtK4EO_2mS92WduAomo1086FRyyrb0=.2dfccee7-d34e-4739-b92f-efb6c969be18@github.com>

On Wed, 16 Jun 2021 01:18:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

> AsyncLogWriter is a subclass of NonJavaThread but not NamedThread. Therefore, 
> is_Named_thread() must not return true.
> 
> Testing: 
> 
> 1. hardcrash scenario:
> ...
> Other Threads:
>   0x00007f2870391f70 VMThread "VM Thread" [stack: 0x00007f2809d7d000,0x00007f2809e7d000] [id=76015]
>   0x00007f28706a1d70 WatcherThread [stack: 0x00007f28082f0000,0x00007f28083f0000] [id=76033]
>   0x00007f28702499b0 AsyncLog Thread [stack: 0x00007f2809e7f000,0x00007f2809f7f000] [id=76014]
> ...
> 
> 2. jcmd $pid Thread.print
> ...
> "AsyncLog Thread" os_prio=0 cpu=1015.24ms elapsed=181.04s tid=0x00007f7b14c57fb0 nid=0x12ed8 runnable
> ...

Seems fine.

Thanks for fixing.

David

src/hotspot/share/runtime/thread.cpp line 651:

> 649:   else if (this == AsyncLogWriter::instance()) {
> 650:     st->print("%s", this->name());
> 651:   } else                                { st->print("Thread"); }

This is a bit kludgy but then the whole name() handling is a mess - I will file a RFE to try and clean that up.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4503

From ysuenaga at openjdk.java.net  Wed Jun 16 04:07:33 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 16 Jun 2021 04:07:33 GMT
Subject: RFR: 8268852: AsyncLogWriter should not overide is_Named_thread()
In-Reply-To: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
References: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
Message-ID: <FVMBuj2Nco9_JN-zkjpvyEymCnRd_EiD0f-Xz3UKDmk=.e4eeeddb-b3b9-4e84-9697-1b4dee212b18@github.com>

On Wed, 16 Jun 2021 01:18:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

> AsyncLogWriter is a subclass of NonJavaThread but not NamedThread. Therefore, 
> is_Named_thread() must not return true.
> 
> Testing: 
> 
> 1. hardcrash scenario:
> ...
> Other Threads:
>   0x00007f2870391f70 VMThread "VM Thread" [stack: 0x00007f2809d7d000,0x00007f2809e7d000] [id=76015]
>   0x00007f28706a1d70 WatcherThread [stack: 0x00007f28082f0000,0x00007f28083f0000] [id=76033]
>   0x00007f28702499b0 AsyncLog Thread [stack: 0x00007f2809e7f000,0x00007f2809f7f000] [id=76014]
> ...
> 
> 2. jcmd $pid Thread.print
> ...
> "AsyncLog Thread" os_prio=0 cpu=1015.24ms elapsed=181.04s tid=0x00007f7b14c57fb0 nid=0x12ed8 runnable
> ...

Looks good, but can we add `is_AsyncLogWriter_thread()` to `Thread` like `is_ConcurrentGC_thread()`?

-------------

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4503

From david.holmes at oracle.com  Wed Jun 16 04:11:21 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 16 Jun 2021 14:11:21 +1000
Subject: RFR: 8268852: AsyncLogWriter should not overide is_Named_thread()
In-Reply-To: <FVMBuj2Nco9_JN-zkjpvyEymCnRd_EiD0f-Xz3UKDmk=.e4eeeddb-b3b9-4e84-9697-1b4dee212b18@github.com>
References: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
 <FVMBuj2Nco9_JN-zkjpvyEymCnRd_EiD0f-Xz3UKDmk=.e4eeeddb-b3b9-4e84-9697-1b4dee212b18@github.com>
Message-ID: <89454c24-6c6a-d974-c66b-4e4de06508c2@oracle.com>

Hi Yasumasa,

On 16/06/2021 2:07 pm, Yasumasa Suenaga wrote:
> On Wed, 16 Jun 2021 01:18:55 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>> AsyncLogWriter is a subclass of NonJavaThread but not NamedThread. Therefore,
>> is_Named_thread() must not return true.
>>
>> Testing:
>>
>> 1. hardcrash scenario:
>> ...
>> Other Threads:
>>    0x00007f2870391f70 VMThread "VM Thread" [stack: 0x00007f2809d7d000,0x00007f2809e7d000] [id=76015]
>>    0x00007f28706a1d70 WatcherThread [stack: 0x00007f28082f0000,0x00007f28083f0000] [id=76033]
>>    0x00007f28702499b0 AsyncLog Thread [stack: 0x00007f2809e7f000,0x00007f2809f7f000] [id=76014]
>> ...
>>
>> 2. jcmd $pid Thread.print
>> ...
>> "AsyncLog Thread" os_prio=0 cpu=1015.24ms elapsed=181.04s tid=0x00007f7b14c57fb0 nid=0x12ed8 runnable
>> ...
> 
> Looks good, but can we add `is_AsyncLogWriter_thread()` to `Thread` like `is_ConcurrentGC_thread()`?

I was going to suggest something similar but instead I've filed a RFE - 
JDK-8268855 - that will get rid of that chunk of code anyway.

Cheers,
David
-----

> -------------
> 
> Marked as reviewed by ysuenaga (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4503
> 

From dholmes at openjdk.java.net  Wed Jun 16 04:11:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 04:11:39 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <CgEd4bONXJ1b5F8QALmCMFV2XwXCpEsBCvcvfaSAQpA=.032cec79-087c-4da8-864c-1fc1afda006d@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Sorry but I do not agree with this change. I understand your rationale but you have overlooked that by combining these three safepoint operations you have created a much longer safepoint pause which may lock out other more important safepoint operations, and you may also be holding the HeapLock across this extended safepoint.

The operations that you have coalesced are not considered time critical but can themselves be very time consuming e.g deadlock detection.

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From ysuenaga at openjdk.java.net  Wed Jun 16 04:20:31 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 16 Jun 2021 04:20:31 GMT
Subject: RFR: 8268852: AsyncLogWriter should not overide is_Named_thread()
In-Reply-To: <89454c24-6c6a-d974-c66b-4e4de06508c2@oracle.com>
References: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
 <89454c24-6c6a-d974-c66b-4e4de06508c2@oracle.com>
Message-ID: <bMaUYdiZlEiehSMkGl7434skmmJWbQ4G7vyD47CFVH4=.59e2b492-87c0-423a-9f76-18e3dd8ae59d@github.com>

On Wed, 16 Jun 2021 04:13:07 GMT, David Holmes <david.holmes at oracle.com> wrote:

> > Looks good, but can we add `is_AsyncLogWriter_thread()` to `Thread` like `is_ConcurrentGC_thread()`?
> 
> I was going to suggest something similar but instead I've filed a RFE -
> JDK-8268855 - that will get rid of that chunk of code anyway.

Sounds good, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4503

From xliu at openjdk.java.net  Wed Jun 16 05:48:29 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Jun 2021 05:48:29 GMT
Subject: RFR: 8268852: AsyncLogWriter should not overide is_Named_thread()
In-Reply-To: <89454c24-6c6a-d974-c66b-4e4de06508c2@oracle.com>
References: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
 <89454c24-6c6a-d974-c66b-4e4de06508c2@oracle.com>
Message-ID: <_9COAXcS7Y5BvD5N9vVWjsY6ffoETXKFNbkD62fXJRc=.aaa30b4e-074b-428f-9bad-c8b8e794d778@github.com>

On Wed, 16 Jun 2021 04:13:07 GMT, David Holmes <david.holmes at oracle.com> wrote:

> Looks good, but can we add `is_AsyncLogWriter_thread()` to `Thread` like `is_ConcurrentGC_thread()`?

Thanks. I think that change is more "global" because it

-------------

PR: https://git.openjdk.java.net/jdk/pull/4503

From jonathanjoo at google.com  Wed Jun 16 09:04:46 2021
From: jonathanjoo at google.com (Jonathan Joo)
Date: Wed, 16 Jun 2021 05:04:46 -0400
Subject: Supported BSD and Windows platforms on JDK17
Message-ID: <CACz-JM4KQVMt_gveEA4dyAaJWsAXxKB4v5Fz_WqemoK12GpREA@mail.gmail.com>

Hello,

I had a quick question about supported platforms for JDK17.

I was looking at
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms, and
wanted to double check two things:

1. Which platform(s) of BSD are officially supported for JDK17?
2. Which version(s) of Windows are officially supported for JDK17?

>From the link it seems that the only BSD platform supported is Mac OS X,
and the only Windows version is Windows 2016. Is it safe to assume that any
code written in hotspot will not have to gracefully handle other BSD
platforms and other Windows versions?

Thank you!

~ Jonathan

From duke at openjdk.java.net  Wed Jun 16 12:19:38 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 16 Jun 2021 12:19:38 GMT
Subject: Withdrawn: 8262953: [TESTBUG] Test
 /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled
In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com>
References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com>
Message-ID: <sOAh-mfzdZJWTQUq3Ihrax6T6OVIUn7AC0S80KWniRE=.c9cfcaf6-482e-425f-84c7-68b7d15ba840@github.com>

On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov <github.com+22177208+aostrouhhov at openjdk.org> wrote:

> Hello!
> Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`.
> 
> This is my first contribution so please tell me if i am wrong somewhere.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3206

From david.holmes at oracle.com  Wed Jun 16 12:22:42 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 16 Jun 2021 22:22:42 +1000
Subject: Supported BSD and Windows platforms on JDK17
In-Reply-To: <CACz-JM4KQVMt_gveEA4dyAaJWsAXxKB4v5Fz_WqemoK12GpREA@mail.gmail.com>
References: <CACz-JM4KQVMt_gveEA4dyAaJWsAXxKB4v5Fz_WqemoK12GpREA@mail.gmail.com>
Message-ID: <2770d691-0be7-767d-7458-c2e0ea64f23c@oracle.com>

Hi Jonathon,

On 16/06/2021 7:04 pm, Jonathan Joo wrote:
> Hello,
> 
> I had a quick question about supported platforms for JDK17.
> 
> I was looking at
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms, and
> wanted to double check two things:
> 
> 1. Which platform(s) of BSD are officially supported for JDK17?
> 2. Which version(s) of Windows are officially supported for JDK17?

You looked at the supported build platforms page but seem to be asking 
about the supported runtime platforms ??

The "officially" supported platforms depend on whose OpenJDK 
implementation you are looking at. The source code supports "BSD" but 
the only BSD-flavor that is built and tested by Oracle, for example, is 
for macOS. But the generic BSD port is still part of OpenJDK and we 
strive (through community contributions) to keep it running.

For Windows, the Oracle supported platforms range from Windows 2012 R2 
upwards IIRC, but unofficially we try to keep older versions running as 
long as is practical, and avoid breaking things unnecessarily.

>  From the link it seems that the only BSD platform supported is Mac OS X,
> and the only Windows version is Windows 2016. Is it safe to assume that any
> code written in hotspot will not have to gracefully handle other BSD
> platforms and other Windows versions?

So no not a safe assumption sorry.

Cheers,
David

> 
> Thank you!
> 
> ~ Jonathan
> 

From coleenp at openjdk.java.net  Wed Jun 16 12:45:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 12:45:39 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v3]
In-Reply-To: <I9Ve6zqAzn7Qkru-s884Kv4jNU2sOQWmE1YlLaY44Jo=.62afc806-a773-4d6d-909d-b3ec23e06d9e@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
 <U20Z6tFeuC--JWe2QIHZuaqu8ot29bHJJg3bcwsc8B0=.ae96f4dd-a5b9-472a-92e0-00b17fb029f3@github.com>
 <wLwWY7Ety5umHOUSBAMPJyqTrR9dNiCG9_SWMST94NQ=.073ea5e3-5ecb-405e-be51-a9e434fe4221@github.com>
 <I9Ve6zqAzn7Qkru-s884Kv4jNU2sOQWmE1YlLaY44Jo=.62afc806-a773-4d6d-909d-b3ec23e06d9e@github.com>
Message-ID: <ShKqoQSIlWcuF_HmRs_MMQ62V17JJui4ym53k6cTTVc=.41b1fc6b-415a-43d1-b5b0-bfbd3c22f754@github.com>

On Wed, 16 Jun 2021 02:25:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Because the new_symbol call will increment the Symbol* refcount in the SymbolTable, it's then copied to the java.lang.String, so the name isn't needed after this.
>
> Ah I see. The types were confusing me. We start with a char* convert to a Symbol, then convert that back to char* but with the externalized format. The irony there being that  it seems these Options start in external format but then get stored in internal format!
> No issue.

Yes, Ioi and I discussed this part of the change but since we substitute slashes for dots and then back again, it is correct.  Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From coleenp at openjdk.java.net  Wed Jun 16 12:45:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 12:45:39 GMT
Subject: RFR: 8267870: Remove unnecessary char_converter during class
 loading [v3]
In-Reply-To: <p9nwl_Oe8ehmdkjgNSymYIyCUrbUG_yA4Z-f4grrMeM=.2aab7342-0a57-4b6a-a7a6-b8a3a0b9108d@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
 <p9nwl_Oe8ehmdkjgNSymYIyCUrbUG_yA4Z-f4grrMeM=.2aab7342-0a57-4b6a-a7a6-b8a3a0b9108d@github.com>
Message-ID: <2UPDRIGyev03vHfaAfS9D_66NhMMi2efdCzadyOlS9o=.d9f8bc1e-9079-4e3f-a078-c84f9c2182b2@github.com>

On Wed, 16 Jun 2021 02:25:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
>> 
>> Tested with tier1-3 in mach5.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix CHECK_NULL.

Thanks David and Ioi for the code reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From coleenp at openjdk.java.net  Wed Jun 16 12:45:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 12:45:40 GMT
Subject: Integrated: 8267870: Remove unnecessary char_converter during class
 loading
In-Reply-To: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
References: <xJB0DvsV5jzfXn2-dD11ZkSleW1fUKTf_LjCOAFetIM=.d301642d-a07b-4897-87ca-ea2cc080bf07@github.com>
Message-ID: <jaJGymiKGGrSoc0Rtmom81KE4ttq_u7LXI3wHaFnBq0=.5146133f-4ad7-4f0d-8018-62c732ba02ed@github.com>

On Mon, 24 May 2021 20:24:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> We create a String object from a Symbol, then swap the '/' for '.' characters, and create another String object.  Seems wasteful.  Removed java_lang_String::char_converted and made externalize_classname take a Symbol.
> 
> Tested with tier1-3 in mach5.

This pull request has now been integrated.

Changeset: af13fe11
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/af13fe110720ff20ccea0a01fe088707208c3dd8
Stats:     78 lines in 5 files changed: 2 ins; 66 del; 10 mod

8267870: Remove unnecessary char_converter during class loading

Reviewed-by: dholmes, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/4173

From hseigel at openjdk.java.net  Wed Jun 16 14:13:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 16 Jun 2021 14:13:48 GMT
Subject: [jdk17] RFR: 8260194: Update the documentation for -Xcheck:jni
 [v2]
In-Reply-To: <bHS2FaA6AK2LmaV5BIsyTmli89bn6RND-tnitjVmK30=.90c027b0-3107-47e2-9f24-6e0d4ca6e062@github.com>
References: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
 <bHS2FaA6AK2LmaV5BIsyTmli89bn6RND-tnitjVmK30=.90c027b0-3107-47e2-9f24-6e0d4ca6e062@github.com>
Message-ID: <WT4TASz_-anEa9tSeT4tYJhuvP04olmNPbpcwZioWpQ=.187f0032-4c59-4729-83fd-eb9d3f14560c@github.com>

On Wed, 16 Jun 2021 01:32:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this update to the -Xcheck:jni description in the java manpage.
>> 
>> For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:
>> 
>> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
>> 
>> A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix name case in jfieldID and jmethodID

Changes look good!
Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/52

From phh at openjdk.java.net  Wed Jun 16 15:08:38 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 16 Jun 2021 15:08:38 GMT
Subject: RFR: 8268638: semaphores of AsyncLogWriter may be broken when JVM
 is exiting. [v5]
In-Reply-To: <q9fUlcuDZqUDdQWrFE_ST9CrovLUDYQGtq3su3A2Vgc=.8965ebfb-ba53-4daa-b98c-b153e08f6eff@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
 <q9fUlcuDZqUDdQWrFE_ST9CrovLUDYQGtq3su3A2Vgc=.8965ebfb-ba53-4daa-b98c-b153e08f6eff@github.com>
Message-ID: <MIkLsRKg0QCoVV-0BVoDnsbcUoxAwxeu-d--HcFXTjA=.bdb61a90-6ce5-4585-8129-6a56fdec653d@github.com>

On Tue, 15 Jun 2021 07:24:10 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
>> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
>> 
>> This patch change those to regular data members. This prevents from deleting.
>> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use AsyncLogWriter::_instance->_lock directly.

Looks good.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4479

From psandoz at openjdk.java.net  Wed Jun 16 15:29:19 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 16 Jun 2021 15:29:19 GMT
Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in
 jdk image [v2]
In-Reply-To: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
References: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
Message-ID: <RmLyjsiluI2cJAgK9zFGX0TI4WLozsc9tE7FS1wJTgo=.28ac9bdf-6b8e-472b-82e9-8debc87db7be@github.com>

> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Require C2.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/47/files
  - new: https://git.openjdk.java.net/jdk17/pull/47/files/a0c66bd6..ed59678e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=47&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=47&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/47/head:pull/47

PR: https://git.openjdk.java.net/jdk17/pull/47

From psandoz at openjdk.java.net  Wed Jun 16 15:37:35 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 16 Jun 2021 15:37:35 GMT
Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in
 jdk image [v2]
In-Reply-To: <jTSJI4jiBPG3H44OEZov8NIe4yA-PPEN6dfa6zhupl8=.4f07b06a-a4cc-43dc-a185-3ccdc0fac685@github.com>
References: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
 <jTSJI4jiBPG3H44OEZov8NIe4yA-PPEN6dfa6zhupl8=.4f07b06a-a4cc-43dc-a185-3ccdc0fac685@github.com>
Message-ID: <k7mMuS7wQ6YQJPg3i2BMkccNvX7NhVajUpCcp2QkDzg=.8c8acbbb-c813-46ba-a008-4e0a9ed2806b@github.com>

On Wed, 16 Jun 2021 01:20:39 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Require C2.
>
> The test logic should be changed.
> 
> If C2 is absent, libsvml.so would not be generated after JDK-8268643.
> Thanks.

@DamonFool thanks. I updated the test to require C2. This is not exactly what i want but i think is sufficient for now.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/47

From coleenp at openjdk.java.net  Wed Jun 16 16:02:53 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 16:02:53 GMT
Subject: RFR: 8259066: Obsolete -XX:+AlwaysLockClassLoader
Message-ID: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>

Trivial change to obsolete a deprecated option.
Tested with tier1-3 (in progress) but no tests use this option.

-------------

Commit messages:
 - 8259066: Obsolete -XX:+AlwaysLockClassLoader

Changes: https://git.openjdk.java.net/jdk/pull/4511/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4511&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259066
  Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4511.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4511/head:pull/4511

PR: https://git.openjdk.java.net/jdk/pull/4511

From hseigel at openjdk.java.net  Wed Jun 16 16:09:40 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 16 Jun 2021 16:09:40 GMT
Subject: RFR: 8259066: Obsolete -XX:+AlwaysLockClassLoader
In-Reply-To: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>
References: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>
Message-ID: <EcBlUIAcDYSU5jtKNWwPtShPsDcTFxnQLozj6zR--TA=.f4b9f809-2761-4a2e-8e8e-2464d5ef77bb@github.com>

On Wed, 16 Jun 2021 15:52:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Trivial change to obsolete a deprecated option.
> Tested with tier1-3 (in progress) but no tests use this option.

Looks good and trivial.
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4511

From iklam at openjdk.java.net  Wed Jun 16 16:09:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 16 Jun 2021 16:09:42 GMT
Subject: RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock
In-Reply-To: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
References: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
Message-ID: <RhcV7lim9P4VGdTkGKxLEXEryiY0PzvmKvbbAAiZ-v4=.bd9e74cd-ff8b-41bb-8589-afe24517b9e5@github.com>

On Tue, 15 Jun 2021 17:07:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fixing a mistake in https://git.openjdk.java.net/jdk/pull/4322
> 
> `SystemDictionaryShared::check_excluded_classes()` iterates over `_dumptime_table`, so we must hold the `DumpTimeTable_lock` first. Otherwise concurrent class unloading may be modifying the `_dumptime_table` while we are still iterating it.
> 
> I also removed an outdated comment.
> 
> (This fix should be backported to JDK 17, but I want to have some mileage on it in the JDK 18 repo first.)

mach5 tiers1-4 passed.
Thanks @calvinccheung and @yminqi for review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4494

From iklam at openjdk.java.net  Wed Jun 16 16:09:43 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 16 Jun 2021 16:09:43 GMT
Subject: Integrated: 8268778: CDS check_excluded_classes needs
 DumpTimeTable_lock
In-Reply-To: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
References: <I7Lm1Nq9ff_Jb3eBREv6E78be4uKW9CDd2ZrQG2P6ug=.8fb4098d-db30-4948-815a-aac5263e41fe@github.com>
Message-ID: <f62I8UawBSkVB42f0WXHBZyEwu06ndaqV29fIlREVnM=.aef41b6b-dfc9-441f-8950-13a143112a80@github.com>

On Tue, 15 Jun 2021 17:07:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fixing a mistake in https://git.openjdk.java.net/jdk/pull/4322
> 
> `SystemDictionaryShared::check_excluded_classes()` iterates over `_dumptime_table`, so we must hold the `DumpTimeTable_lock` first. Otherwise concurrent class unloading may be modifying the `_dumptime_table` while we are still iterating it.
> 
> I also removed an outdated comment.
> 
> (This fix should be backported to JDK 17, but I want to have some mileage on it in the JDK 18 repo first.)

This pull request has now been integrated.

Changeset: e4908a43
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4908a439a235ee437c0e6e39341e1d67904f49e
Stats:     10 lines in 3 files changed: 5 ins; 3 del; 2 mod

8268778: CDS check_excluded_classes needs DumpTimeTable_lock

Reviewed-by: ccheung, minqi

-------------

PR: https://git.openjdk.java.net/jdk/pull/4494

From coleenp at openjdk.java.net  Wed Jun 16 16:11:13 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 16:11:13 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
Message-ID: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>

The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.

Tested with tier1-6.

-------------

Commit messages:
 - 8268902: Testing for threadObj != NULL is unnecessary in handshake

Changes: https://git.openjdk.java.net/jdk/pull/4512/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4512&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268902
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4512/head:pull/4512

PR: https://git.openjdk.java.net/jdk/pull/4512

From coleenp at openjdk.java.net  Wed Jun 16 16:11:14 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 16:11:14 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <FLyQLa1fcD9m1g6vVpR5ER6UMhkMi9XSnr7j-vVKR1g=.05476156-48e4-4c0f-8f02-d461a260a270@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

We can't remove all the checks for threadObj for NULL since there are places, particularly in JVMTI that use this test for threads that are newly created.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From coleenp at openjdk.java.net  Wed Jun 16 16:37:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 16:37:41 GMT
Subject: RFR: 8259066: Obsolete -XX:+AlwaysLockClassLoader
In-Reply-To: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>
References: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>
Message-ID: <2-fOM0zDwqMJguV5fCbKiSH4sNx2tEmyspet2CGbf-c=.753290cd-ed35-4e4e-bf60-f7443c60ce17@github.com>

On Wed, 16 Jun 2021 15:52:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Trivial change to obsolete a deprecated option.
> Tested with tier1-3 (in progress) but no tests use this option.

Thanks Harold!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4511

From coleenp at openjdk.java.net  Wed Jun 16 16:37:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 16:37:43 GMT
Subject: Integrated: 8259066: Obsolete -XX:+AlwaysLockClassLoader
In-Reply-To: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>
References: <wL7NBCPezXsAIRN_Nim_NKmK6nYciUMOVgpk7mhbNWA=.bace6c82-b5ef-4e81-8ad8-5609da9789ad@github.com>
Message-ID: <Gp3SGBMUb2DYoBP7YtW3M8HIiDiMmLmeWHOEebCxYnc=.d5465bbd-14c8-4cf0-a20f-64525adbf541@github.com>

On Wed, 16 Jun 2021 15:52:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Trivial change to obsolete a deprecated option.
> Tested with tier1-3 (in progress) but no tests use this option.

This pull request has now been integrated.

Changeset: c20f80a4
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c20f80a4d2e8d0f5995ad44a38e838adbff6068d
Stats:     6 lines in 2 files changed: 0 ins; 6 del; 0 mod

8259066: Obsolete -XX:+AlwaysLockClassLoader

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/jdk/pull/4511

From dcubed at openjdk.java.net  Wed Jun 16 16:46:43 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 16:46:43 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <lfR9QqwPk-EKkTaORed_4Z0tq-fTVGLUHYQo1OXvPYg=.49ff7589-0c5a-4750-ad47-a2d677e7f5d2@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

Changes requested by dcubed (Reviewer).

src/hotspot/share/runtime/handshake.cpp line 629:

> 627:   assert(_handshakee->threadObj() != NULL,
> 628:          "null threadobj is impossible because we're handshaking while the thread is being created");
> 629:   if (_handshakee->is_exiting()) {

The assert() is racy when it comes before the `_handshakee->is_exiting()` check.
It is possible for the target thread (`_handshakee`) to set the exiting condition:

src/hotspot/share/runtime/thread.cpp: JavaThread::exit():

    set_terminated(_thread_exiting);

and call:

  ensure_join(this);

which clears the `_threadObj` field while the caller has just
called `HandshakeState::suspend_with_handshake()`.
The caller would then fail the assert() when racing with the
exiting thread when what you want it to do is detect the
exiting condition and return false.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From dcubed at openjdk.java.net  Wed Jun 16 17:03:35 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 17:03:35 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <lfR9QqwPk-EKkTaORed_4Z0tq-fTVGLUHYQo1OXvPYg=.49ff7589-0c5a-4750-ad47-a2d677e7f5d2@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
 <lfR9QqwPk-EKkTaORed_4Z0tq-fTVGLUHYQo1OXvPYg=.49ff7589-0c5a-4750-ad47-a2d677e7f5d2@github.com>
Message-ID: <Ni5KD7HT45PM03JpsYI5is2_oNJSeQ3ThLCibxSDrrQ=.3d7e8133-a04d-43c6-af7a-43050d3e5f9b@github.com>

On Wed, 16 Jun 2021 16:33:41 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
>> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
>> 
>> Tested with tier1-6.
>
> src/hotspot/share/runtime/handshake.cpp line 629:
> 
>> 627:   assert(_handshakee->threadObj() != NULL,
>> 628:          "null threadobj is impossible because we're handshaking while the thread is being created");
>> 629:   if (_handshakee->is_exiting()) {
> 
> The assert() is racy when it comes before the `_handshakee->is_exiting()` check.
> It is possible for the target thread (`_handshakee`) to set the exiting condition:
> 
> src/hotspot/share/runtime/thread.cpp: JavaThread::exit():
> 
>     set_terminated(_thread_exiting);
> 
> and call:
> 
>   ensure_join(this);
> 
> which clears the `_threadObj` field while the caller has just
> called `HandshakeState::suspend_with_handshake()`.
> The caller would then fail the assert() when racing with the
> exiting thread when what you want it to do is detect the
> exiting condition and return false.

Update: After re-reading more of the code, I think I have to change
my comment here. The code above (`HandshakeState::suspend_with_handshake()`)
is called from SuspendThreadHandshake::do_thread() which is a synchronous
handshake. The caller requesting the synchronous handshake cannot proceed until
the target thread is handshakeable. When the target thread is in `JavaThread::exit()`
it is in thread state `_thread_in_vm` and that's not a safe/handshakeable state so
the calling thread must wait for the target thread to become handshakeable or for
the exiting condition to be true. No race here is possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From dcubed at openjdk.java.net  Wed Jun 16 17:06:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 17:06:40 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <83eUs7KyBsFvln2B7iGNhdVzrxdaCLddXudDfcsS_Aw=.295c8c2a-fc76-4ca3-95bc-3efd9ab938e5@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

Thumbs up (after revising my comments).

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4512

From dfuchs at openjdk.java.net  Wed Jun 16 19:22:57 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Jun 2021 19:22:57 GMT
Subject: [jdk17] Integrated: 8268909: ProblemList
 jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64
In-Reply-To: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
References: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
Message-ID: <oLmkWG-HQxkERpAgok_-NO6fWLax-V1jWPYXYGr--HI=.1b8ae55c-e96c-4a5e-a1b0-215961af8181@github.com>

On Wed, 16 Jun 2021 19:11:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/84

From mikael at openjdk.java.net  Wed Jun 16 19:22:56 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Wed, 16 Jun 2021 19:22:56 GMT
Subject: [jdk17] Integrated: 8268909: ProblemList
 jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64
In-Reply-To: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
References: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
Message-ID: <kKrO87__SeyyRx8jYY3UAUd6kfhdcsdJYrNnywbPXkA=.a06d9fa9-b956-44f2-8bbc-85191e785be2@github.com>

On Wed, 16 Jun 2021 19:11:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/84

From dcubed at openjdk.java.net  Wed Jun 16 19:22:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 19:22:59 GMT
Subject: [jdk17] Integrated: 8268909: ProblemList
 jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64
In-Reply-To: <kKrO87__SeyyRx8jYY3UAUd6kfhdcsdJYrNnywbPXkA=.a06d9fa9-b956-44f2-8bbc-85191e785be2@github.com>
References: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
 <kKrO87__SeyyRx8jYY3UAUd6kfhdcsdJYrNnywbPXkA=.a06d9fa9-b956-44f2-8bbc-85191e785be2@github.com>
Message-ID: <A3JxFs31rEZ1ZxG-6yirwdlJqrR7Uvqbpoqh2JZwESc=.52c57dd5-21c1-43b0-b603-4e392a2a05f5@github.com>

On Wed, 16 Jun 2021 19:15:49 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik and @dfuch - Thanks for the fast reviews!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/84

From dcubed at openjdk.java.net  Wed Jun 16 19:23:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 19:23:00 GMT
Subject: [jdk17] Integrated: 8268909: ProblemList
 jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64
In-Reply-To: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
References: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>
Message-ID: <RJogwjdK3JIePtCiJ6n3M0_qf8Pimpnv6PDFLPprAVo=.4192dd0f-5eff-4624-b52d-108b12ae7795@github.com>

On Wed, 16 Jun 2021 19:11:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64.

This pull request has now been integrated.

Changeset: f0f21788
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/f0f2178876813cca070db01ce37ea7a04b712923
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268909: ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64

Reviewed-by: mikael, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk17/pull/84

From dcubed at openjdk.java.net  Wed Jun 16 19:22:56 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 19:22:56 GMT
Subject: [jdk17] Integrated: 8268909: ProblemList
 jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64
Message-ID: <yq3fng2k8Mqg3oXP49Qk-T4n1rECdDUWDJn75ymGR0I=.d404f303-ed5d-4387-a781-ffa0725072a5@github.com>

A trivial fix to ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64.

-------------

Commit messages:
 - 8268909: ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64

Changes: https://git.openjdk.java.net/jdk17/pull/84/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=84&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268909
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/84/head:pull/84

PR: https://git.openjdk.java.net/jdk17/pull/84

From hseigel at openjdk.java.net  Wed Jun 16 20:41:02 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 16 Jun 2021 20:41:02 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v2]
In-Reply-To: <Vakhi9kYZMUQIb0q6-2TbNwMcBp93Vtl7yRsJqREUCw=.dba73ffc-590c-4274-83a8-7a5927111066@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <Vakhi9kYZMUQIb0q6-2TbNwMcBp93Vtl7yRsJqREUCw=.dba73ffc-590c-4274-83a8-7a5927111066@github.com>
Message-ID: <ve1Ojtx7jm8AsOJGNkNOCKLCgxCJSFy_sOo7OnTFDxw=.e400ac95-93f2-40d8-9eab-6b38a128d98b@github.com>

On Wed, 16 Jun 2021 00:49:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comments, removed unneeded 'retur;'
>
> src/hotspot/share/classfile/classFileParser.cpp line 714:
> 
>> 712:             } else if (!Signature::is_void_method(signature)) { // must have void return
>> 713:               throwIllegalSignature("Method", name, signature, CHECK);
>> 714:               return;
> 
> So this is the check that is now skipped when doing the NameAndType_info check. In which case the comment should be expanded to something like:
> 
> " ... it must be <init\> and must have a void signature"
> 
> also the comment at line 697:
> 
> // Method name and signature are verified above, when iterating NameAndType_info.
> 
> may no longer be accurate.

Hi David, Thanks for reviewing this.  Please review this small update containing mostly comment changes.
Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From hseigel at openjdk.java.net  Wed Jun 16 20:40:57 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 16 Jun 2021 20:40:57 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v2]
In-Reply-To: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
Message-ID: <n-niGG-H_MiMPX3LesZYz_fmeB9HCrCUrQWkJgcrWcY=.eb27784e-5917-4107-9a39-ea3ef9c29138@github.com>

> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
> 
> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
> 
> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
> 
> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  updated comments, removed unneeded 'retur;'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4497/files
  - new: https://git.openjdk.java.net/jdk/pull/4497/files/62c2858b..094a71a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4497/head:pull/4497

PR: https://git.openjdk.java.net/jdk/pull/4497

From coleenp at openjdk.java.net  Wed Jun 16 21:36:19 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 21:36:19 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <Ni5KD7HT45PM03JpsYI5is2_oNJSeQ3ThLCibxSDrrQ=.3d7e8133-a04d-43c6-af7a-43050d3e5f9b@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
 <lfR9QqwPk-EKkTaORed_4Z0tq-fTVGLUHYQo1OXvPYg=.49ff7589-0c5a-4750-ad47-a2d677e7f5d2@github.com>
 <Ni5KD7HT45PM03JpsYI5is2_oNJSeQ3ThLCibxSDrrQ=.3d7e8133-a04d-43c6-af7a-43050d3e5f9b@github.com>
Message-ID: <UwScb7dX8qXUveVTSqFFUqPwUqAz1zx-cmYeWk3ca18=.03b93da1-376e-492d-b144-f9d8f16c235a@github.com>

On Wed, 16 Jun 2021 17:00:03 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/handshake.cpp line 629:
>> 
>>> 627:   assert(_handshakee->threadObj() != NULL,
>>> 628:          "null threadobj is impossible because we're handshaking while the thread is being created");
>>> 629:   if (_handshakee->is_exiting()) {
>> 
>> The assert() is racy when it comes before the `_handshakee->is_exiting()` check.
>> It is possible for the target thread (`_handshakee`) to set the exiting condition:
>> 
>> src/hotspot/share/runtime/thread.cpp: JavaThread::exit():
>> 
>>     set_terminated(_thread_exiting);
>> 
>> and call:
>> 
>>   ensure_join(this);
>> 
>> which clears the `_threadObj` field while the caller has just
>> called `HandshakeState::suspend_with_handshake()`.
>> The caller would then fail the assert() when racing with the
>> exiting thread when what you want it to do is detect the
>> exiting condition and return false.
>
> Update: After re-reading more of the code, I think I have to change
> my comment here. The code above (`HandshakeState::suspend_with_handshake()`)
> is called from SuspendThreadHandshake::do_thread() which is a synchronous
> handshake. The caller requesting the synchronous handshake cannot proceed until
> the target thread is handshakeable. When the target thread is in `JavaThread::exit()`
> it is in thread state `_thread_in_vm` and that's not a safe/handshakeable state so
> the calling thread must wait for the target thread to become handshakeable or for
> the exiting condition to be true. No race here is possible.

Yes, the _handshakee thread - or target thread can't do suspend_with_handshake unless it's in a safe state, so the ensure_join() function must have completed or not been called.  Also ensure_join() clears the ThreadObj's Thread field but the JavaThread->_threadObj field isn't cleared:

  java_lang_Thread::set_thread(threadObj(), NULL);

The _threadObj field isn't cleared until the JavaThread* destructor so this code should not have a reference to JavaThread at this point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From coleenp at openjdk.java.net  Wed Jun 16 21:42:16 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 21:42:16 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <_e4d1Q33Ue9WKpjRTAUZYdfPBLHVgD9T0VDTFF3I1yE=.39551f42-2904-4553-a420-194757c9d351@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

Thanks for the review, Dan!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From jiefu at openjdk.java.net  Wed Jun 16 23:08:13 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Jun 2021 23:08:13 GMT
Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in
 jdk image [v2]
In-Reply-To: <RmLyjsiluI2cJAgK9zFGX0TI4WLozsc9tE7FS1wJTgo=.28ac9bdf-6b8e-472b-82e9-8debc87db7be@github.com>
References: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
 <RmLyjsiluI2cJAgK9zFGX0TI4WLozsc9tE7FS1wJTgo=.28ac9bdf-6b8e-472b-82e9-8debc87db7be@github.com>
Message-ID: <cJkvRK7bGDNF9Ej7vSaQ9TiLycdu6jNSR1eBU2dYb8E=.236456b3-83fd-4bf7-9019-23fe53eea81b@github.com>

On Wed, 16 Jun 2021 15:29:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require C2.

LGTM
Thanks for your update.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/47

From dholmes at openjdk.java.net  Wed Jun 16 23:57:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 23:57:18 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v2]
In-Reply-To: <n-niGG-H_MiMPX3LesZYz_fmeB9HCrCUrQWkJgcrWcY=.eb27784e-5917-4107-9a39-ea3ef9c29138@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <n-niGG-H_MiMPX3LesZYz_fmeB9HCrCUrQWkJgcrWcY=.eb27784e-5917-4107-9a39-ea3ef9c29138@github.com>
Message-ID: <nn6a-iPUXIbS89k5Pg-31FQDhmh_x1CRheFNuksN7jg=.b1b18573-4b17-4a3d-93b9-e9a95d97ce92@github.com>

On Wed, 16 Jun 2021 20:40:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
>> 
>> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
>> 
>> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
>> 
>> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comments, removed unneeded 'retur;'

Looks good!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4497

From xliu at openjdk.java.net  Wed Jun 16 23:58:20 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Jun 2021 23:58:20 GMT
Subject: Integrated: 8268852: AsyncLogWriter should not overide
 is_Named_thread()
In-Reply-To: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
References: <D5TK-HyYPLqVNsV7UDsRctWuJtcTyy94c9xq_bW-mZI=.2a999639-0f4f-4aa3-bdc8-7f2734e360db@github.com>
Message-ID: <v8soD5_1y42rQMANn0r0216EbL4uFtyJ2T9Px2BVF_A=.7a631e43-8461-48e7-b353-ef9acedb631a@github.com>

On Wed, 16 Jun 2021 01:18:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

> AsyncLogWriter is a subclass of NonJavaThread but not NamedThread. Therefore, 
> is_Named_thread() must not return true.
> 
> Testing: 
> 
> 1. hardcrash scenario:
> ...
> Other Threads:
>   0x00007f2870391f70 VMThread "VM Thread" [stack: 0x00007f2809d7d000,0x00007f2809e7d000] [id=76015]
>   0x00007f28706a1d70 WatcherThread [stack: 0x00007f28082f0000,0x00007f28083f0000] [id=76033]
>   0x00007f28702499b0 AsyncLog Thread [stack: 0x00007f2809e7f000,0x00007f2809f7f000] [id=76014]
> ...
> 
> 2. jcmd $pid Thread.print
> ...
> "AsyncLog Thread" os_prio=0 cpu=1015.24ms elapsed=181.04s tid=0x00007f7b14c57fb0 nid=0x12ed8 runnable
> ...

This pull request has now been integrated.

Changeset: 02c9bf08
Author:    Xin Liu <xliu at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02c9bf087e50885bbc8028415c4e674947ee7a16
Stats:     4 lines in 2 files changed: 2 ins; 1 del; 1 mod

8268852: AsyncLogWriter should not overide is_Named_thread()

Reviewed-by: dholmes, ysuenaga

-------------

PR: https://git.openjdk.java.net/jdk/pull/4503

From dholmes at openjdk.java.net  Wed Jun 16 23:58:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 23:58:15 GMT
Subject: [jdk17] RFR: 8260194: Update the documentation for -Xcheck:jni
 [v2]
In-Reply-To: <bHS2FaA6AK2LmaV5BIsyTmli89bn6RND-tnitjVmK30=.90c027b0-3107-47e2-9f24-6e0d4ca6e062@github.com>
References: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
 <bHS2FaA6AK2LmaV5BIsyTmli89bn6RND-tnitjVmK30=.90c027b0-3107-47e2-9f24-6e0d4ca6e062@github.com>
Message-ID: <QD_YiL7FDufIGDENQRUKVvpGr-aI-Z_Redk0MTl_JiA=.17fd1688-4695-4497-8356-33a223735f45@github.com>

On Wed, 16 Jun 2021 01:32:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this update to the -Xcheck:jni description in the java manpage.
>> 
>> For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:
>> 
>> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
>> 
>> A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix name case in jfieldID and jmethodID

Thanks for the review Harold!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/52

From dholmes at openjdk.java.net  Thu Jun 17 00:02:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 00:02:14 GMT
Subject: [jdk17] Integrated: 8260194: Update the documentation for -Xcheck:jni
In-Reply-To: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
References: <et1yfrBbyB6lzFT_ZDCDlJYdA_7OY6r13RiEijyV7xg=.ddf95b3a-e21e-4fdb-8a5e-f22ac5c97a01@github.com>
Message-ID: <exHgEVLG7Zyon40B3mUuo48gjl0j8OWwsAJhvT4Hq2A=.232f192a-2708-4f73-9746-441407c3930a@github.com>

On Tue, 15 Jun 2021 10:09:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this update to the -Xcheck:jni description in the java manpage.
> 
> For ease of reading there was a temporary commit of the generated java.html page. This can be viewed here:
> 
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
> 
> A preemptive note on the punctuation of the lists. The  first and second level level list items are all complete sentences and so end with a period. The third level list items are phrases, not full sentences and so do not end with a period. :)
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 9f7851b5
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/9f7851b5f5220132fce8556269851e33ac06ef31
Stats:     68 lines in 1 file changed: 62 ins; 6 del; 0 mod

8260194: Update the documentation for -Xcheck:jni

Reviewed-by: coleenp, hseigel

-------------

PR: https://git.openjdk.java.net/jdk17/pull/52

From ddong at openjdk.java.net  Thu Jun 17 02:35:19 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 02:35:19 GMT
Subject: Withdrawn: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <obsmGPzcA1Gf7dFPJJtQXA4Y2M4T6-Ta6UeWC9SIQgU=.9f7cda78-c922-4197-ae22-0533798650c0@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From ddong at openjdk.java.net  Thu Jun 17 02:35:18 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 02:35:18 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <CgEd4bONXJ1b5F8QALmCMFV2XwXCpEsBCvcvfaSAQpA=.032cec79-087c-4da8-864c-1fc1afda006d@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <CgEd4bONXJ1b5F8QALmCMFV2XwXCpEsBCvcvfaSAQpA=.032cec79-087c-4da8-864c-1fc1afda006d@github.com>
Message-ID: <VhVEvG0D9Kz4D9bhvVZ5F60zUaKY1H7rqXUc9q8BksQ=.cb95334d-b68e-4098-adc9-b303458d1808@github.com>

On Wed, 16 Jun 2021 04:08:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I do not agree with this change. I understand your rationale but you have overlooked that by combining these three safepoint operations you have created a much longer safepoint pause which may lock out other more important safepoint operations, and you may also be holding the HeapLock across this extended safepoint.
> 
> The operations that you have coalesced are not considered time critical but can themselves be very time consuming e.g deadlock detection.
> 
> David

Hi David,

Thanks for the comment.

I still think it's redundant to enter three safepoint, which may lead to inconsistent results between 'PrintThreads' and 'FindDeadlocks'. But this patch does cause the problem you said

I will reopen it once I have a better solution.

Thanks,
Denghui

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From stuefe at openjdk.java.net  Thu Jun 17 04:20:12 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 04:20:12 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <xrESicFFOhQe62MT45h9T3CH_Pe62Z61Es6XC3C8DNc=.4a72dcc0-0528-4575-9811-78d44a0b21e2@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

It would be nice to have this fixed though. Maybe adding a guaranteed timeout to these operations would help.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From ddong at openjdk.java.net  Thu Jun 17 05:15:36 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 05:15:36 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v2]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <3hM_tItjj51zsVQIrYIE7_3sR8j5A2ijdxKNbHmla_w=.f87dde43-a467-41cf-8bb0-e8a40b8d5d2b@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with three additional commits since the last revision:

 - update
 - remove useless comment
 - remove VM_PrintJNI

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/82a35b85..56cd2a8b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=00-01

  Stats: 38 lines in 5 files changed: 4 ins; 28 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

PR: https://git.openjdk.java.net/jdk/pull/4504

From dholmes at openjdk.java.net  Thu Jun 17 05:58:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 05:58:26 GMT
Subject: RFR: 8268927: Windows: link error: unresolved external symbol "int
 __cdecl convert_to_unicode(char const *, wchar_t * *)"
Message-ID: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>

Please review this trivial fix to add a missing "static" to a function prototype. For some reason VS 16.9.3+ doesn't treat this as an error but earlier versions do (and gcc/g++ confirms).

Tested our CI builds remain okay with this change.

Thanks,
David

-------------

Commit messages:
 - 8268927: Windows: link error: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar_t * *)"

Changes: https://git.openjdk.java.net/jdk/pull/4516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4516&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268927
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4516/head:pull/4516

PR: https://git.openjdk.java.net/jdk/pull/4516

From dholmes at openjdk.java.net  Thu Jun 17 06:11:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 06:11:07 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v2]
In-Reply-To: <3hM_tItjj51zsVQIrYIE7_3sR8j5A2ijdxKNbHmla_w=.f87dde43-a467-41cf-8bb0-e8a40b8d5d2b@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <3hM_tItjj51zsVQIrYIE7_3sR8j5A2ijdxKNbHmla_w=.f87dde43-a467-41cf-8bb0-e8a40b8d5d2b@github.com>
Message-ID: <RXTD2jCmFgLI7qyvvTtmtMIiqQEmeGc3bVqfQGHpBto=.c4734e08-59d7-4eb3-8af9-65805c870407@github.com>

On Thu, 17 Jun 2021 05:15:36 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update
>  - remove useless comment
>  - remove VM_PrintJNI

So the PR is open again but I see no substantive changes that address my concerns. I don't see how there can be any fix here when the desired goal is one safepoint and the problem is that one safepoint may be far too long. And I don't see any way to force a timeout in a VM operation, or anything it calls.

I realize there can be a discrepancy between the sets of threads involved, but I think that is just the trade-off we have to make for this diagnostic tool.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From stuefe at openjdk.java.net  Thu Jun 17 06:41:33 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 06:41:33 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
Message-ID: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>

The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.

This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.

The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.

This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.

Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
- when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
- as a stop gap measure it allows to release pressure from a high footprint scenario.

Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.

I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.

If this finds agreement, I will file a CSR.

=========

This patch:

- introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
- includes a (rather basic) test
- the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
- I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.

=========

Example:

A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:



thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
                   ^^^^^^^^


We execute the new trim command via jcmd:


thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
18770:
Attempting trim...
Done.
Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
Swap before: 0k, after: 0k, (0k)


It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:


thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
                   ^^^^^^^


When the VM is started with -Xlog:os, this is also logged:


[139,068s][info][os] malloc_trim:
[139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)
Swap before: 0k, after: 0k, (0k)

-------------

Commit messages:
 - start

Changes: https://git.openjdk.java.net/jdk/pull/4510/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268893
  Stats: 237 lines in 6 files changed: 212 ins; 7 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Thu Jun 17 06:43:17 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 06:43:17 GMT
Subject: RFR: 8268927: Windows: link error: unresolved external symbol
 "int __cdecl convert_to_unicode(char const *, wchar_t * *)"
In-Reply-To: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>
References: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>
Message-ID: <BQX80CLoWowvLxVZlYlyQUW-XnOXEHI2EoG44bEFSCQ=.dc238240-2374-425d-9306-adccd2085127@github.com>

On Thu, 17 Jun 2021 05:50:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to add a missing "static" to a function prototype. For some reason VS 16.9.3+ doesn't treat this as an error but earlier versions do (and gcc/g++ confirms).
> 
> Tested our CI builds remain okay with this change.
> 
> Thanks,
> David

Looks good and trivial.

..Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4516

From iklam at openjdk.java.net  Thu Jun 17 06:51:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Jun 2021 06:51:40 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive
Message-ID: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>

In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.

When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.

For size saving, we should avoid writing such duplicated classes into the archive.

(Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)

Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.

-------------

Commit messages:
 - fixed whitespaces
 - avoid using the word "unique" since it is ambiguous
 - cleanup
 - Merge branch 'master' into 8267189-dup-unreg-classes-dyn-archive
 - cleanup
 - Merge branch 'master' into 8267189-dup-unreg-classes-dyn-archive
 - group by loaders before checking for class duplication
 - added comments; try to exclude duplicated classes by classloader
 - Merge branch 'master' into 8267189-dup-unreg-classes-dyn-archive
 - step1

Changes: https://git.openjdk.java.net/jdk/pull/4515/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4515&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267189
  Stats: 319 lines in 8 files changed: 300 ins; 2 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4515.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4515/head:pull/4515

PR: https://git.openjdk.java.net/jdk/pull/4515

From dholmes at openjdk.java.net  Thu Jun 17 07:06:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 07:06:13 GMT
Subject: Integrated: 8268927: Windows: link error: unresolved external symbol
 "int __cdecl convert_to_unicode(char const *, wchar_t * *)"
In-Reply-To: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>
References: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>
Message-ID: <JymHDKU0YCFm-ZHRwvjxc47HrhdR7yJGqcT7QqxbDrc=.0ca70f19-a21e-412e-874e-ab1a3ab22b38@github.com>

On Thu, 17 Jun 2021 05:50:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to add a missing "static" to a function prototype. For some reason VS 16.9.3+ doesn't treat this as an error but earlier versions do (and gcc/g++ confirms).
> 
> Tested our CI builds remain okay with this change.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: e8446107
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e84461072af9cdb2ee83f5c0747ea5881a0ae805
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8268927: Windows: link error: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar_t * *)"

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.java.net/jdk/pull/4516

From dholmes at openjdk.java.net  Thu Jun 17 07:06:12 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 07:06:12 GMT
Subject: RFR: 8268927: Windows: link error: unresolved external symbol
 "int __cdecl convert_to_unicode(char const *, wchar_t * *)"
In-Reply-To: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>
References: <xFHZf22LVFCxSfU072O23hZtARgGK4wRJ0-Sj7E-Gwg=.2f1b2016-6758-46e4-a126-99558fe95c65@github.com>
Message-ID: <GGt3whVGhvjWDXqZ_yinYSqpDXjZAzMgFg_ZYy6fz-0=.44f1d78f-a594-4e2d-b11b-497b4a98a8c1@github.com>

On Thu, 17 Jun 2021 05:50:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to add a missing "static" to a function prototype. For some reason VS 16.9.3+ doesn't treat this as an error but earlier versions do (and gcc/g++ confirms).
> 
> Tested our CI builds remain okay with this change.
> 
> Thanks,
> David

Thanks Thomas!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4516

From sgehwolf at openjdk.java.net  Thu Jun 17 08:34:11 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 17 Jun 2021 08:34:11 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <5EdNrljfk5N4trdLY5AaHPYbp1kx5ZMZmrMEW_wyc90=.c57a2937-8447-41c9-ace4-a2b72a3e05be@github.com>

On Wed, 16 Jun 2021 12:57:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
> 
> If this finds agreement, I will file a CSR.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                    ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                    ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)

src/hotspot/os/linux/os_linux.hpp line 186:

> 184:     ssize_t rssanon;    // resident set size
> 185:     ssize_t rssfile;    // resident set size
> 186:     ssize_t rssshmem;   // resident set size

Are these comments intionally the same for all three? Seems weird.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Thu Jun 17 08:37:12 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 08:37:12 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
In-Reply-To: <5EdNrljfk5N4trdLY5AaHPYbp1kx5ZMZmrMEW_wyc90=.c57a2937-8447-41c9-ace4-a2b72a3e05be@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <5EdNrljfk5N4trdLY5AaHPYbp1kx5ZMZmrMEW_wyc90=.c57a2937-8447-41c9-ace4-a2b72a3e05be@github.com>
Message-ID: <rxSSCthgxDB888_mNkLAv8Ryc93jI_Ompo5dQwldhmI=.912cea66-18b5-414f-a57e-dfac5e3d29e2@github.com>

On Thu, 17 Jun 2021 08:25:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> src/hotspot/os/linux/os_linux.hpp line 186:
> 
>> 184:     ssize_t rssanon;    // resident set size
>> 185:     ssize_t rssfile;    // resident set size
>> 186:     ssize_t rssshmem;   // resident set size
> 
> Are these comments intionally the same for all three? Seems weird.

Nope, copy paste error. Thanks for catching.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Thu Jun 17 08:53:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 08:53:55 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>

> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
> 
> If this finds agreement, I will file a CSR.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                    ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                    ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Feedback Severin; renamed query function

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4510/files
  - new: https://git.openjdk.java.net/jdk/pull/4510/files/97d71ea7..a48791e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510

PR: https://git.openjdk.java.net/jdk/pull/4510

From psandoz at openjdk.java.net  Thu Jun 17 14:58:37 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 17 Jun 2021 14:58:37 GMT
Subject: [jdk17] Integrated: 8268353: Test libsvml.so is and is not present in
 jdk image
In-Reply-To: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
References: <cCn_TtEDXxC7VmcZvKWN8mGcvkI63Sq6dGGSmAJ68m8=.2b2b71de-bff7-423e-a301-d6d7a333ccc0@github.com>
Message-ID: <6k4yu7pnj3kiZ_MISPhvFHSQxZ-6BaQbXy5UiC9_Ugs=.948a238b-8773-42d4-9940-0fdb14cdec03@github.com>

On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case.

This pull request has now been integrated.

Changeset: 091bc4a1
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/091bc4a1a6ca687aab0c9064f11408b93511a520
Stats:     100 lines in 2 files changed: 97 ins; 0 del; 3 mod

8268353: Test libsvml.so is and is not present in jdk image

Reviewed-by: sviswanathan, jiefu

-------------

PR: https://git.openjdk.java.net/jdk17/pull/47

From ddong at openjdk.java.net  Thu Jun 17 15:32:01 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 15:32:01 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with two additional commits since the last revision:

 - add cutoff support for find_deadlocks_at_safepoint
 - remove useless field '_is_deadlock'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/56cd2a8b..42faa20b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=01-02

  Stats: 53 lines in 4 files changed: 36 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

PR: https://git.openjdk.java.net/jdk/pull/4504

From dcubed at openjdk.java.net  Thu Jun 17 16:43:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Jun 2021 16:43:40 GMT
Subject: [jdk17] RFR: 8268971: ProblemList
 tools/jpackage/windows/WinInstallerIconTest.java on win-x64
Message-ID: <WBuZlWskhV0GQP6SMX_Bj770IMnH5F5id7RUbukSTTU=.8d4b2a42-267f-441a-8c94-9530e99c6582@github.com>

A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64.

-------------

Commit messages:
 - 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

Changes: https://git.openjdk.java.net/jdk17/pull/90/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=90&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268971
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/90.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/90/head:pull/90

PR: https://git.openjdk.java.net/jdk17/pull/90

From dcubed at openjdk.java.net  Thu Jun 17 16:56:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Jun 2021 16:56:27 GMT
Subject: [jdk17] RFR: 8268971: ProblemList
 tools/jpackage/windows/WinInstallerIconTest.java on win-x64
In-Reply-To: <U8Q4qrjd3KkSpVDDN0dt7TF4R-h_d7vCgwRGYQHyI6E=.8965bd02-3ad2-4cdb-a448-7f38316d2826@github.com>
References: <WBuZlWskhV0GQP6SMX_Bj770IMnH5F5id7RUbukSTTU=.8d4b2a42-267f-441a-8c94-9530e99c6582@github.com>
 <U8Q4qrjd3KkSpVDDN0dt7TF4R-h_d7vCgwRGYQHyI6E=.8965bd02-3ad2-4cdb-a448-7f38316d2826@github.com>
Message-ID: <u2FXSZWIOelv-i0ZGiczwcgXdZrNBycbEra3DbLb8Hw=.ab96fd47-46a8-4502-b464-a2502b5d5066@github.com>

On Thu, 17 Jun 2021 16:49:49 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64.
>
> Marked as reviewed by herrick (Reviewer).

@andyherrick - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/90

From herrick at openjdk.java.net  Thu Jun 17 16:56:26 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 17 Jun 2021 16:56:26 GMT
Subject: [jdk17] RFR: 8268971: ProblemList
 tools/jpackage/windows/WinInstallerIconTest.java on win-x64
In-Reply-To: <WBuZlWskhV0GQP6SMX_Bj770IMnH5F5id7RUbukSTTU=.8d4b2a42-267f-441a-8c94-9530e99c6582@github.com>
References: <WBuZlWskhV0GQP6SMX_Bj770IMnH5F5id7RUbukSTTU=.8d4b2a42-267f-441a-8c94-9530e99c6582@github.com>
Message-ID: <U8Q4qrjd3KkSpVDDN0dt7TF4R-h_d7vCgwRGYQHyI6E=.8965bd02-3ad2-4cdb-a448-7f38316d2826@github.com>

On Thu, 17 Jun 2021 16:32:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/90

From dcubed at openjdk.java.net  Thu Jun 17 16:56:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Jun 2021 16:56:27 GMT
Subject: [jdk17] Integrated: 8268971: ProblemList
 tools/jpackage/windows/WinInstallerIconTest.java on win-x64
In-Reply-To: <WBuZlWskhV0GQP6SMX_Bj770IMnH5F5id7RUbukSTTU=.8d4b2a42-267f-441a-8c94-9530e99c6582@github.com>
References: <WBuZlWskhV0GQP6SMX_Bj770IMnH5F5id7RUbukSTTU=.8d4b2a42-267f-441a-8c94-9530e99c6582@github.com>
Message-ID: <sEO5adlLUhwMHQc6mRSCsR9Nuhbo-9aypbStWSU6VRY=.2421fcb2-1060-42b3-b2ab-0f99dd41d9a5@github.com>

On Thu, 17 Jun 2021 16:32:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64.

This pull request has now been integrated.

Changeset: b66001a5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/b66001a5946252b621bab27d6ee32006a4d7bab5
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

Reviewed-by: herrick

-------------

PR: https://git.openjdk.java.net/jdk17/pull/90

From minqi at openjdk.java.net  Thu Jun 17 18:11:27 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 17 Jun 2021 18:11:27 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive
In-Reply-To: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
Message-ID: <i-wTu7-o6aNWMaoRj90LItEPCNMfgMtuNWfvKdd5Mvo=.c5b98280-051a-4835-819f-8334cebbc175@github.com>

On Thu, 17 Jun 2021 04:03:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
> 
> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
> 
> For size saving, we should avoid writing such duplicated classes into the archive.
> 
> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
> 
> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DuplicatedCustomTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2021, Oracle and/or its affiliates. All rights reserved.

New added file only need the added year.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/DuplicatedCustomApp.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2021, Oracle and/or its affiliates. All rights reserved.

Same here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4515

From minqi at openjdk.java.net  Thu Jun 17 18:28:35 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 17 Jun 2021 18:28:35 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive
In-Reply-To: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
Message-ID: <kijU8IgZaEmckpoADyIv_hPARIoDAKBgqXY_E_6QGEQ=.55b62065-05bc-4222-ae7e-17c064ae7607@github.com>

On Thu, 17 Jun 2021 04:03:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
> 
> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
> 
> For size saving, we should avoid writing such duplicated classes into the archive.
> 
> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
> 
> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1511:

> 1509: class UnregisteredClassesDuplicationChecker : StackObj {
> 1510:   GrowableArray<InstanceKlass*> _list;
> 1511:   Thread* _thread;

seems _thread only used at line 1542, could remove the field and use Thread::current() in the site.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1529:

> 1527:       return intx(loader_a) - intx(loader_b);
> 1528:     } else {
> 1529:       return intx(a[0]) -intx(b[0]);

space after "-"

-------------

PR: https://git.openjdk.java.net/jdk/pull/4515

From lfoltan at openjdk.java.net  Thu Jun 17 18:59:26 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Thu, 17 Jun 2021 18:59:26 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v2]
In-Reply-To: <n-niGG-H_MiMPX3LesZYz_fmeB9HCrCUrQWkJgcrWcY=.eb27784e-5917-4107-9a39-ea3ef9c29138@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <n-niGG-H_MiMPX3LesZYz_fmeB9HCrCUrQWkJgcrWcY=.eb27784e-5917-4107-9a39-ea3ef9c29138@github.com>
Message-ID: <_4uO5jsFXStidEfOTYSDKIHDw9iOQFD2UBqTUvgXUXY=.4c0f2ad4-74dc-430e-8e5e-2e685e507039@github.com>

On Wed, 16 Jun 2021 20:40:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
>> 
>> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
>> 
>> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
>> 
>> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comments, removed unneeded 'retur;'

Hi Harold,

Looks good, but I have a question about passing no_name.

src/hotspot/share/classfile/classFileParser.cpp line 644:

> 642:             // Pass no_name so method name doesn't affect check for legal signature.
> 643:             const Symbol* const no_name = vmSymbols::type_name(); // place holder
> 644:             verify_legal_method_signature(no_name, sig, CHECK);

verify_legal_method_signature() has the potential to throw an exception.  Now it will have no name to include in that exception message concerning an illegal method signature.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From pchilanomate at openjdk.java.net  Thu Jun 17 19:52:00 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 17 Jun 2021 19:52:00 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18
Message-ID: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>

Hi all,

Please review the following patch which handles the removal of biased locking code. 

The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 

Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.

For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.

There are some tests that were only meaningful when run with biased locking enabled so I removed them.

Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.

Thanks,
Patricio

-------------

Commit messages:
 - Update java manpage
 - 8256425: Obsolete Biased Locking in JDK 18

Changes: https://git.openjdk.java.net/jdk/pull/4522/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256425
  Stats: 5283 lines in 163 files changed: 66 ins; 4994 del; 223 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From xliu at openjdk.java.net  Thu Jun 17 20:31:29 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 17 Jun 2021 20:31:29 GMT
Subject: Integrated: 8268638: semaphores of AsyncLogWriter may be broken when
 JVM is exiting.
In-Reply-To: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
References: <xljDyKHb0Lf3NAAF0FPwauMaHdd1qPekdWk_Ye8ij9E=.eee65370-3308-4425-8a25-968f5277a5d2@github.com>
Message-ID: <hrZH24h8wmh84YNeaiRwwoxx0f9CR_6kYS3XOu24sjs=.748c808b-60c6-4602-8c99-cce9258f1776@github.com>

On Sun, 13 Jun 2021 01:01:43 GMT, Xin Liu <xliu at openjdk.org> wrote:

> All 3 semaphores used by AsyncLogWriter are static member data. CRT(`libsystem_c.dylib __cxa_finalize_ranges`) deletes them on MacOS. Currently, AsyncLog Thread doesn't exit at all. As a result, semaphore_wait/signal
> returns with KERN_INVALID_NAME(15) After those semaphore are destroyed. 
> 
> This patch change those to regular data members. This prevents from deleting.
> This patch also provides a general RAII class AsyncLogLocker which is analogous MutexLocker.

This pull request has now been integrated.

Changeset: fa3b44d4
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa3b44d43811dca8c609d6c61a58680835abf8e3
Stats:     22 lines in 2 files changed: 6 ins; 7 del; 9 mod

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Reviewed-by: dholmes, phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/4479

From ccheung at openjdk.java.net  Thu Jun 17 20:32:30 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 17 Jun 2021 20:32:30 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive
In-Reply-To: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
Message-ID: <tSHmWO2jcvXw674LaCYS8petaUtjLZ5GMI0hos8m_KU=.9511cc10-34bc-4e00-8a2e-bcb83f694ab8@github.com>

On Thu, 17 Jun 2021 04:03:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
> 
> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
> 
> For size saving, we should avoid writing such duplicated classes into the archive.
> 
> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
> 
> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.

Looks good. Just some minor suggestions.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1321:

> 1319:     MutexLocker ml(Thread::current(), UnregisteredClassesTable_lock);
> 1320:     Symbol* name = klass->name();
> 1321:     InstanceKlass** v = _unregistered_classes_table->get(name);

`name` is used only once. Maybe just pass `klass->name()` to `get()`?

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DuplicatedCustomTest.java line 88:

> 86:             .assertNormalExit(output -> {
> 87:                 output.shouldContain("DuplicatedCustomApp source: shared objects file")
> 88:                       .shouldContain("CustomLoadee source: shared objects file")

Since the classes will be loaded from dynamic CDS archive. Maybe add " (top)" to the end of the strings?

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/DuplicatedCustomApp.java line 88:

> 86:         System.out.println("Loader = " + c.getClassLoader());
> 87: 
> 88:         // [1] Check that CustomLoadee is defined by the correct loader

The comment may not be accurate since different classes are being passed into this method.
Perhaps change it to the following?
// Check that the loaded class is defined by the correct loader

-------------

Changes requested by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4515

From iklam at openjdk.java.net  Thu Jun 17 20:55:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Jun 2021 20:55:54 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive [v2]
In-Reply-To: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
Message-ID: <IJk5L8lHDP-PJLjBqEU50pq4ndci8PxOfUsGkHiZuUc=.8495d016-6f05-45a9-81ad-bc2c6badc16f@github.com>

> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
> 
> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
> 
> For size saving, we should avoid writing such duplicated classes into the archive.
> 
> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
> 
> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  comments from @calvinccheung and @yminqi

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4515/files
  - new: https://git.openjdk.java.net/jdk/pull/4515/files/49bea3da..0acd58a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4515&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4515&range=00-01

  Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4515.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4515/head:pull/4515

PR: https://git.openjdk.java.net/jdk/pull/4515

From iklam at openjdk.java.net  Thu Jun 17 20:55:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Jun 2021 20:55:55 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive [v2]
In-Reply-To: <kijU8IgZaEmckpoADyIv_hPARIoDAKBgqXY_E_6QGEQ=.55b62065-05bc-4222-ae7e-17c064ae7607@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
 <kijU8IgZaEmckpoADyIv_hPARIoDAKBgqXY_E_6QGEQ=.55b62065-05bc-4222-ae7e-17c064ae7607@github.com>
Message-ID: <4noFm06CSITzl7_lc89ia4ZRcxhMaNJZ9Tk876oP1N8=.01250493-ab66-4f66-8739-caabcfddb996@github.com>

On Thu, 17 Jun 2021 18:25:43 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from @calvinccheung and @yminqi
>
> src/hotspot/share/classfile/systemDictionaryShared.cpp line 1511:
> 
>> 1509: class UnregisteredClassesDuplicationChecker : StackObj {
>> 1510:   GrowableArray<InstanceKlass*> _list;
>> 1511:   Thread* _thread;
> 
> seems _thread only used at line 1542, could remove the field and use Thread::current() in the site.

_thread is used in the loop that iterates over all the classes in the _dumptime_table, so I wanted to avoid calling Thread::current() for each iteration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4515

From ccheung at openjdk.java.net  Thu Jun 17 21:12:29 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 17 Jun 2021 21:12:29 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive [v2]
In-Reply-To: <IJk5L8lHDP-PJLjBqEU50pq4ndci8PxOfUsGkHiZuUc=.8495d016-6f05-45a9-81ad-bc2c6badc16f@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
 <IJk5L8lHDP-PJLjBqEU50pq4ndci8PxOfUsGkHiZuUc=.8495d016-6f05-45a9-81ad-bc2c6badc16f@github.com>
Message-ID: <ulhfGka_SMvta8KqEhYljBNU7RCp2F8w6tORadDYzZY=.fe39de99-fdc2-4cf5-8021-65d97c24ac8d@github.com>

On Thu, 17 Jun 2021 20:55:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
>> 
>> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
>> 
>> For size saving, we should avoid writing such duplicated classes into the archive.
>> 
>> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
>> 
>> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from @calvinccheung and @yminqi

Marked as reviewed by ccheung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4515

From minqi at openjdk.java.net  Thu Jun 17 21:17:29 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 17 Jun 2021 21:17:29 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive [v2]
In-Reply-To: <IJk5L8lHDP-PJLjBqEU50pq4ndci8PxOfUsGkHiZuUc=.8495d016-6f05-45a9-81ad-bc2c6badc16f@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
 <IJk5L8lHDP-PJLjBqEU50pq4ndci8PxOfUsGkHiZuUc=.8495d016-6f05-45a9-81ad-bc2c6badc16f@github.com>
Message-ID: <obMgkCL1dCKStIV7UJCtH9pKlbMi1xbpUiGqN-fkxIM=.2d87a2bf-7cdb-4e7f-9d93-5e7961c15672@github.com>

On Thu, 17 Jun 2021 20:55:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
>> 
>> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
>> 
>> For size saving, we should avoid writing such duplicated classes into the archive.
>> 
>> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
>> 
>> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from @calvinccheung and @yminqi

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4515

From iklam at openjdk.java.net  Thu Jun 17 22:22:37 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Jun 2021 22:22:37 GMT
Subject: RFR: 8267189: Remove duplicated unregistered classes from dynamic
 archive [v2]
In-Reply-To: <obMgkCL1dCKStIV7UJCtH9pKlbMi1xbpUiGqN-fkxIM=.2d87a2bf-7cdb-4e7f-9d93-5e7961c15672@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
 <IJk5L8lHDP-PJLjBqEU50pq4ndci8PxOfUsGkHiZuUc=.8495d016-6f05-45a9-81ad-bc2c6badc16f@github.com>
 <obMgkCL1dCKStIV7UJCtH9pKlbMi1xbpUiGqN-fkxIM=.2d87a2bf-7cdb-4e7f-9d93-5e7961c15672@github.com>
Message-ID: <HQP7M8ZAerkRa8K4UlTDHYGGrW2x3f37C6YX4l23gpc=.5b779a56-a80e-44cd-adda-cd6661481e36@github.com>

On Thu, 17 Jun 2021 21:14:04 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from @calvinccheung and @yminqi
>
> LGTM.

Thanks @yminqi and @calvinccheung for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4515

From iklam at openjdk.java.net  Thu Jun 17 22:22:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Jun 2021 22:22:39 GMT
Subject: Integrated: 8267189: Remove duplicated unregistered classes from
 dynamic archive
In-Reply-To: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
References: <eIU1tS_QG_p1mwTcgFNkwvWiw6r8g4RhkLPRWLtI8zw=.4b264f6a-505d-4ea1-8e0e-7bcc839b484c@github.com>
Message-ID: <IiKYmZ8g694mDFcLx1JHcPzbl95mZ0HMx-8mCNKSoAQ=.68c4aab9-bfa3-4f86-a140-fd2c8130304b@github.com>

On Thu, 17 Jun 2021 04:03:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In the CDS archive, "unregistered" classes are those to be loaded by custom loaders.
> 
> When doing a CDS dynamic dump (with -XX:ArchiveClassesAtExit=foo.jsa), a class of the same name may be loaded by several custom class loaders. Currently we write all of these unregistered classes into the archive. However, only one copy of them will be usable at runtime.
> 
> For size saving, we should avoid writing such duplicated classes into the archive.
> 
> (Note that this problem does not affect the CDS static dump, which is driven by a classlist file. We already disallow duplicate unregistered classes in the classlist.)
> 
> Testing: mach5 tiers 1-4. Also tested locally with Eclipse IDE.

This pull request has now been integrated.

Changeset: bb24fa65
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb24fa652aa1edc8ece8713f559be2fe3437d666
Stats:     318 lines in 8 files changed: 299 ins; 2 del; 17 mod

8267189: Remove duplicated unregistered classes from dynamic archive

Reviewed-by: ccheung, minqi

-------------

PR: https://git.openjdk.java.net/jdk/pull/4515

From dholmes at openjdk.java.net  Thu Jun 17 23:15:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 23:15:25 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
Message-ID: <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>

On Thu, 17 Jun 2021 15:32:01 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add cutoff support for find_deadlocks_at_safepoint
>  - remove useless field '_is_deadlock'

Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From xliu at openjdk.java.net  Thu Jun 17 23:29:59 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 17 Jun 2021 23:29:59 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v4]
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <JUpCD1ymbIFtgWla6x7zfbdZ2JLlNZ1sPszQ79lThME=.6338573d-ba4f-4151-a710-00bf176f2b26@github.com>

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Use Atomic::load/store for decorators.
  
  This patch also installed a sanity check which will assert that
  LogOutput::_decorators is subset of LogDecocrations. It will disclose
  more information if the assertion fails.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4408/files
  - new: https://git.openjdk.java.net/jdk/pull/4408/files/4d2de713..f279f263

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=02-03

  Stats: 85 lines in 8 files changed: 71 ins; 5 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Fri Jun 18 01:21:59 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 18 Jun 2021 01:21:59 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v5]
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <eBVL4DPlFVC0MF2y2sWDO-U1xvti95CMIeTIqu943lY=.6e524bb9-e78e-4f76-9b38-9f27cfaa7d74@github.com>

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Fix VC++ warning C4099

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4408/files
  - new: https://git.openjdk.java.net/jdk/pull/4408/files/f279f263..157a0658

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408

PR: https://git.openjdk.java.net/jdk/pull/4408

From kvn at openjdk.java.net  Fri Jun 18 01:56:27 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 18 Jun 2021 01:56:27 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <6SkM2mxuRj_IXbux_5Ip5sdYc1aR-UGM-uHcma3PXM0=.f512b6e0-6ada-415d-8a93-b62a1aeb71db@github.com>

On Thu, 17 Jun 2021 15:37:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Very nice clean up. Thank you. I have small nitpick and question about BiasedLocking flags deprecation. Obsolete flags [table](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L537) says: ```{ "UseBiasedLocking",             JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) },```

It means in JDK 18 JVM have to accept flags on command line but issue warning.
May be I mistaking, but it means you can not remove flags declaration.
You can remove corresponding code.

src/hotspot/cpu/ppc/vm_version_ppc.cpp line 382:

> 380:   if (UseRTMLocking) {
> 381:     // If CPU or OS do not support TM:
> 382:     // Can't continue because UseRTMLocking affects UseBiasedLocking flag

Can you fix in previous line `TM` -> `RTM`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From david.holmes at oracle.com  Fri Jun 18 02:00:01 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 12:00:01 +1000
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v4]
In-Reply-To: <JUpCD1ymbIFtgWla6x7zfbdZ2JLlNZ1sPszQ79lThME=.6338573d-ba4f-4151-a710-00bf176f2b26@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <JUpCD1ymbIFtgWla6x7zfbdZ2JLlNZ1sPszQ79lThME=.6338573d-ba4f-4151-a710-00bf176f2b26@github.com>
Message-ID: <8d4209d0-9938-d7c2-b01b-73b826f5ed0a@oracle.com>

Hi Xin,

On 18/06/2021 9:29 am, Xin Liu wrote:
>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
> 
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Use Atomic::load/store for decorators.
>    
>    This patch also installed a sanity check which will assert that
>    LogOutput::_decorators is subset of LogDecocrations. It will disclose
>    more information if the assertion fails.

I'm putting these latest changes through tier6 and 7 testing - but there 
is a big backlog at the moment so I don't know when I will get results.

Looking at the code I still find it very difficult to see what actions 
can happen concurrently and what mechanism ensure correct concurrent 
actions. The wait_until_no_readers() logic doesn't make sense to me as I 
can't see what stops the number of readers from increasing the moment 
after it was read as zero! The relationships between all the different 
objects is far from clear to me.

David
-----

> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/4408/files
>    - new: https://git.openjdk.java.net/jdk/pull/4408/files/4d2de713..f279f263
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=03
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=02-03
> 
>    Stats: 85 lines in 8 files changed: 71 ins; 5 del; 9 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408
> 
> PR: https://git.openjdk.java.net/jdk/pull/4408
> 

From ddong at openjdk.java.net  Fri Jun 18 02:29:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 02:29:25 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
 <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
Message-ID: <tBn8E4Fi3YBPEgmNfngIVp66iEOpjqQp83dNM4Iyyhg=.e57a2613-c30f-41f2-8835-d168f4a81b81@github.com>

On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.
> 
> David

Hi David,

Thanks for the comment.

Yes, there is no good way to determine a suitable deadline.

I intend to temporarily give up the idea of combining VM_FindDeadlocks into VM_ExtendedPrintThreads.

But I think we can at least merge `VM_PrintJNI` and `VM_PrintThreads`, because the implementation of `VM_PrintJNI` is very fast. What do you think?

Denghui

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From david.holmes at oracle.com  Fri Jun 18 03:17:15 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 13:17:15 +1000
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18
In-Reply-To: <6SkM2mxuRj_IXbux_5Ip5sdYc1aR-UGM-uHcma3PXM0=.f512b6e0-6ada-415d-8a93-b62a1aeb71db@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <6SkM2mxuRj_IXbux_5Ip5sdYc1aR-UGM-uHcma3PXM0=.f512b6e0-6ada-415d-8a93-b62a1aeb71db@github.com>
Message-ID: <f9ac9473-ed7b-0716-c915-b2f09132b5b4@oracle.com>

On 18/06/2021 11:56 am, Vladimir Kozlov wrote:
> 
> Very nice clean up. Thank you. I have small nitpick and question about BiasedLocking flags deprecation. Obsolete flags [table](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L537) says: ```{ "UseBiasedLocking",             JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) },```
> 
> It means in JDK 18 JVM have to accept flags on command line but issue warning.

Correct.

> May be I mistaking, but it means you can not remove flags declaration.

You can remove the flag (and must). Obsolete flags are handled purely by 
lookup in the obsolete flag table. Once a flag is obsoleted there should 
only be one occurrence left of it in the source code - in that table. :)

Cheers,
David
-----

> You can remove corresponding code.
> 
> src/hotspot/cpu/ppc/vm_version_ppc.cpp line 382:
> 
>> 380:   if (UseRTMLocking) {
>> 381:     // If CPU or OS do not support TM:
>> 382:     // Can't continue because UseRTMLocking affects UseBiasedLocking flag
> 
> Can you fix in previous line `TM` -> `RTM`
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4522
> 

From david.holmes at oracle.com  Fri Jun 18 03:20:37 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 13:20:37 +1000
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <tBn8E4Fi3YBPEgmNfngIVp66iEOpjqQp83dNM4Iyyhg=.e57a2613-c30f-41f2-8835-d168f4a81b81@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
 <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
 <tBn8E4Fi3YBPEgmNfngIVp66iEOpjqQp83dNM4Iyyhg=.e57a2613-c30f-41f2-8835-d168f4a81b81@github.com>
Message-ID: <d6336655-520d-04f7-17dc-4f25335e4c16@oracle.com>

On 18/06/2021 12:29 pm, Denghui Dong wrote:
> On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.
>>
>> David
> 
> Hi David,
> 
> Thanks for the comment.
> 
> Yes, there is no good way to determine a suitable deadline.
> 
> I intend to temporarily give up the idea of combining VM_FindDeadlocks into VM_ExtendedPrintThreads.
> 
> But I think we can at least merge `VM_PrintJNI` and `VM_PrintThreads`, because the implementation of `VM_PrintJNI` is very fast. What do you think?

Yes that seems fine in terms of lengthening the safepoint.

Thanks,
David
-----

> Denghui
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4504
> 

From ddong at openjdk.java.net  Fri Jun 18 05:51:54 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 05:51:54 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v4]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <XPYkVnhOiPDmbZL2NoOZZQniQaZI-A1Rfk8V0OeuSoM=.8057d194-cab0-400d-b81b-4248a71ddf0e@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/42faa20b..01a0308d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=02-03

  Stats: 67 lines in 7 files changed: 12 ins; 42 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

PR: https://git.openjdk.java.net/jdk/pull/4504

From dholmes at openjdk.java.net  Fri Jun 18 06:01:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 18 Jun 2021 06:01:29 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <ejuXXvrKuGhExPXfVg009Ore8L80ypum2tHX58QxQVA=.2e5d0c84-7426-4ed1-b764-4a9ac241f861@github.com>

On Thu, 17 Jun 2021 15:37:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Hi Patricio,

Huge cleanup! Looks great to see so much red. :)

I looked through everything and have a few minor comments below. Can't comment in detail on JIT changes (or whether further improvements are possible) but it all looks okay from an "eradicate biased-locking" perspective.

Thanks,
David

src/hotspot/share/code/nmethod.hpp line 281:

> 279:   // will never cause Class instances to be biased but this code
> 280:   // handles the static synchronized case as well.
> 281:   // JVMTI's GetLocalInstance() also uses these offsets to find the receiver

Not obvious that this entire comment is no longer relevant. The basic description of the use of the offsets seems applicable even if not actually needed for revoking the bias.

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java line 156:

> 154:     long prototypeMarkWord() {
> 155:         return markWordNoHashInPlace | markWordNoLockInPlace;
> 156:     }

It is not immediately obvious that this is correct for all object types. Does this match what the initial_mark() is now?

test/hotspot/jtreg/compiler/c2/Test8062950.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved.

I'd argue this test serves no purpose now.

test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java line 65:

> 63:                 // Inflate locks[handshakee] if possible
> 64:                 System.identityHashCode(locks[handshakee]);
> 65:                 walked = wb.handshakeReadMonitors(workingThreads[handshakee]);

It is not at all obvious that this revised test and the new WB routine actually test what was previously being tested. Do we actually need to involve monitors here or is that just something that has been picked to examine while in a handshake?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4522

From ddong at openjdk.java.net  Fri Jun 18 06:08:48 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:08:48 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v5]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  polish

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/01a0308d..bec65ddb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=03-04

  Stats: 33 lines in 5 files changed: 6 ins; 21 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

PR: https://git.openjdk.java.net/jdk/pull/4504

From david.holmes at oracle.com  Fri Jun 18 06:12:20 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 16:12:20 +1000
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v4]
In-Reply-To: <8d4209d0-9938-d7c2-b01b-73b826f5ed0a@oracle.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <JUpCD1ymbIFtgWla6x7zfbdZ2JLlNZ1sPszQ79lThME=.6338573d-ba4f-4151-a710-00bf176f2b26@github.com>
 <8d4209d0-9938-d7c2-b01b-73b826f5ed0a@oracle.com>
Message-ID: <5a5e5f50-2a89-1bf9-d2cc-ee296ef89ce0@oracle.com>

On 18/06/2021 12:00 pm, David Holmes wrote:
> Hi Xin,
> 
> On 18/06/2021 9:29 am, Xin Liu wrote:
>>> Support dynamic reconfiguration for async logging. 2 unittests are 
>>> provided.
>>> The regression test discovers a race condition in LogTagSet::log() 
>>> even with
>>> synchronous logging. It's not MT-safe if context switch happens 
>>> between the
>>> creation of LogDecorations? and LogOutputList::Iterator. fixed.
>>
>> Xin Liu has updated the pull request incrementally with one additional 
>> commit since the last revision:
>>
>> ?? Use Atomic::load/store for decorators.
>> ?? This patch also installed a sanity check which will assert that
>> ?? LogOutput::_decorators is subset of LogDecocrations. It will disclose
>> ?? more information if the assertion fails.
> 
> I'm putting these latest changes through tier6 and 7 testing - but there 
> is a big backlog at the moment so I don't know when I will get results.

Not complete yet but the asynclogTest failed again:

- one crash with the SEGV in flockfile
- one crash with assert(bitmask == _decorators._decorators) failed: 
LogOutput: 4095 decorations: 0 message = ConcurrentLogsite 0 emits a log

David
-----

> Looking at the code I still find it very difficult to see what actions 
> can happen concurrently and what mechanism ensure correct concurrent 
> actions. The wait_until_no_readers() logic doesn't make sense to me as I 
> can't see what stops the number of readers from increasing the moment 
> after it was read as zero! The relationships between all the different 
> objects is far from clear to me.
> 
> David
> -----
> 
>> -------------
>>
>> Changes:
>> ?? - all: https://git.openjdk.java.net/jdk/pull/4408/files
>> ?? - new: 
>> https://git.openjdk.java.net/jdk/pull/4408/files/4d2de713..f279f263
>>
>> Webrevs:
>> ? - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=03
>> ? - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=02-03
>>
>> ?? Stats: 85 lines in 8 files changed: 71 ins; 5 del; 9 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/4408/head:pull/4408
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4408
>>

From yyang at openjdk.java.net  Fri Jun 18 06:17:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:17:30 GMT
Subject: RFR: 8268425: Show integer nid of OSThread instead of hex format
 one
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>

On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang <yyang at openjdk.org> wrote:

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Do you think this would facilitate debugging process? And is it acceptable? Any feedback is appreciated!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From xliu at openjdk.java.net  Fri Jun 18 06:23:34 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 18 Jun 2021 06:23:34 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v5]
In-Reply-To: <eBVL4DPlFVC0MF2y2sWDO-U1xvti95CMIeTIqu943lY=.6e524bb9-e78e-4f76-9b38-9f27cfaa7d74@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <eBVL4DPlFVC0MF2y2sWDO-U1xvti95CMIeTIqu943lY=.6e524bb9-e78e-4f76-9b38-9f27cfaa7d74@github.com>
Message-ID: <m_UJk69ma2Lmk1ryxz-zolc0RLMwsBrzMlHIIDNG9V0=.d89dbd71-6aa7-4b00-8d0e-d17c821b6b2a@github.com>

On Fri, 18 Jun 2021 01:21:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix VC++ warning C4099

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 18/06/2021 12:00 pm, David Holmes wrote:
> 
> > Hi Xin,
> > On 18/06/2021 9:29 am, Xin Liu wrote:
> > > > Support dynamic reconfiguration for async logging. 2 unittests are
> > > > provided.
> > > > The regression test discovers a race condition in LogTagSet::log()
> > > > even with
> > > > synchronous logging. It's not MT-safe if context switch happens
> > > > between the
> > > > creation of LogDecorations? and LogOutputList::Iterator. fixed.
> > > 
> > > 
> > > Xin Liu has updated the pull request incrementally with one additional
> > > commit since the last revision:
> > > ?? Use Atomic::load/store for decorators.
> > > ?? This patch also installed a sanity check which will assert that
> > > ?? LogOutput::_decorators is subset of LogDecocrations. It will disclose
> > > ?? more information if the assertion fails.
> > 
> > 
> > I'm putting these latest changes through tier6 and 7 testing - but there
> > is a big backlog at the moment so I don't know when I will get results.
> 
> Not complete yet but the asynclogTest failed again:
> 
> - one crash with the SEGV in flockfile
> - one crash with assert(bitmask == _decorators._decorators) failed:
> LogOutput: 4095 decorations: 0 message = ConcurrentLogsite 0 emits a log
> 
> David
> -----
> 
> > Looking at the code I still find it very difficult to see what actions
> > can happen concurrently and what mechanism ensure correct concurrent
> > actions. The wait_until_no_readers() logic doesn't make sense to me as I
> > can't see what stops the number of readers from increasing the moment
> > after it was read as zero! The relationships between all the different
> > objects is far from clear to me.
> > David
> > -----

Thank you. I see. we haven't solved any of two crash sights.  
Current synchronization mechanism doesn't work for both tags or decorators.  
Let me think of it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From dholmes at openjdk.java.net  Fri Jun 18 06:27:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 18 Jun 2021 06:27:26 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v5]
In-Reply-To: <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>
Message-ID: <mif25qZxdkgaRq7v1m0Q_HSaUlSHbcKBFA3v0zVzdg4=.639bdff7-63e0-47f3-b487-51782554f924@github.com>

On Fri, 18 Jun 2021 06:08:48 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   polish

This looks much better. A few minor code changes requested - and possibly a big simplification.

Thanks,
David

src/hotspot/share/runtime/os.cpp line 402:

> 400:         // the output stream (e.g. tty->flush()) after output.  See 4803766.
> 401:         // Each module also prints an extra carriage return after its output.
> 402:         VM_PrintThreads op(tty, PrintConcurrentLocks, false, true);

Please comment what the false/true arguments mean e.g.

... false /* no extended info */, true /* print JNI handle info */);

src/hotspot/share/runtime/vmOperation.hpp line 112:

> 110:   template(JFROldObject)                          \
> 111:   template(JvmtiPostObjectFree)                   \
> 112:   template(ExtendedPrintThreads)

This change is not needed now.

src/hotspot/share/runtime/vmOperations.hpp line 146:

> 144:   bool _print_concurrent_locks;
> 145:   bool _print_extended_info;
> 146:   bool _print_jni;

Please call this _print_jni_handle_info and update parameter names accordingly.

Though it seems we never pass false here and so always print the JNI handle info, in which case we can get rid of the field and the parameter.

src/hotspot/share/runtime/vmOperations.hpp line 150:

> 148:   VM_PrintThreads()
> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
> 150:   {}

This no-arg constructor is unused now.

src/hotspot/share/runtime/vmOperations.hpp line 151:

> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
> 150:   {}
> 151:   VM_PrintThreads(outputStream* out, bool print_concurrent_locks, bool print_extended_info, bool print_jni = false)

As far as I can see you don't rely on the default parameter value so it is not needed.

src/hotspot/share/services/attachListener.cpp line 187:

> 185: 
> 186:   // thread stacks and JNI global handles
> 187:   VM_PrintThreads op1(out, print_concurrent_locks, print_extended_info, true);

Please comment what the true argument means.

src/hotspot/share/services/diagnosticCommand.cpp line 538:

> 536: void ThreadDumpDCmd::execute(DCmdSource source, TRAPS) {
> 537:   // thread stacks and JNI global handles
> 538:   VM_PrintThreads op1(output(), _locks.value(), _extended.value(), true);

Please comment what the true argument means.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4504

From ddong at openjdk.java.net  Fri Jun 18 06:46:01 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:46:01 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v6]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <LFHDL0U6xGKZuTj0KkSNQ7ngoMMgJZ9y4oWX2_Scis4=.a6a4d9f9-1fbe-4bc7-9176-5306d6e8ea66@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update according to the comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/bec65ddb..c9a65726

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=04-05

  Stats: 10 lines in 6 files changed: 0 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

PR: https://git.openjdk.java.net/jdk/pull/4504

From ddong at openjdk.java.net  Fri Jun 18 06:51:57 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:51:57 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v5]
In-Reply-To: <mif25qZxdkgaRq7v1m0Q_HSaUlSHbcKBFA3v0zVzdg4=.639bdff7-63e0-47f3-b487-51782554f924@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>
 <mif25qZxdkgaRq7v1m0Q_HSaUlSHbcKBFA3v0zVzdg4=.639bdff7-63e0-47f3-b487-51782554f924@github.com>
Message-ID: <XrNsDu43EJ9n8i0e1h1G2vQeen4qWtQejC9TvmW5S-8=.b8b7eb1b-9a43-49f5-a0f8-4b32313d22df@github.com>

On Fri, 18 Jun 2021 06:17:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   polish
>
> src/hotspot/share/runtime/os.cpp line 402:
> 
>> 400:         // the output stream (e.g. tty->flush()) after output.  See 4803766.
>> 401:         // Each module also prints an extra carriage return after its output.
>> 402:         VM_PrintThreads op(tty, PrintConcurrentLocks, false, true);
> 
> Please comment what the false/true arguments mean e.g.
> 
> ... false /* no extended info */, true /* print JNI handle info */);

fixed.

> src/hotspot/share/runtime/vmOperation.hpp line 112:
> 
>> 110:   template(JFROldObject)                          \
>> 111:   template(JvmtiPostObjectFree)                   \
>> 112:   template(ExtendedPrintThreads)
> 
> This change is not needed now.

fixed.

> src/hotspot/share/runtime/vmOperations.hpp line 146:
> 
>> 144:   bool _print_concurrent_locks;
>> 145:   bool _print_extended_info;
>> 146:   bool _print_jni;
> 
> Please call this _print_jni_handle_info and update parameter names accordingly.
> 
> Though it seems we never pass false here and so always print the JNI handle info, in which case we can get rid of the field and the parameter.

fixed.

> src/hotspot/share/runtime/vmOperations.hpp line 150:
> 
>> 148:   VM_PrintThreads()
>> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
>> 150:   {}
> 
> This no-arg constructor is unused now.

the no-arg  constructor is used by JVM_DumpAllStacks now.

> src/hotspot/share/runtime/vmOperations.hpp line 151:
> 
>> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
>> 150:   {}
>> 151:   VM_PrintThreads(outputStream* out, bool print_concurrent_locks, bool print_extended_info, bool print_jni = false)
> 
> As far as I can see you don't rely on the default parameter value so it is not needed.

fixed

> src/hotspot/share/services/attachListener.cpp line 187:
> 
>> 185: 
>> 186:   // thread stacks and JNI global handles
>> 187:   VM_PrintThreads op1(out, print_concurrent_locks, print_extended_info, true);
> 
> Please comment what the true argument means.

fixed

> src/hotspot/share/services/diagnosticCommand.cpp line 538:
> 
>> 536: void ThreadDumpDCmd::execute(DCmdSource source, TRAPS) {
>> 537:   // thread stacks and JNI global handles
>> 538:   VM_PrintThreads op1(output(), _locks.value(), _extended.value(), true);
> 
> Please comment what the true argument means.

fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From ddong at openjdk.java.net  Fri Jun 18 06:51:53 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:51:53 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/c9a65726..a9c0e177

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4504&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

PR: https://git.openjdk.java.net/jdk/pull/4504

From dholmes at openjdk.java.net  Fri Jun 18 07:08:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 18 Jun 2021 07:08:32 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <9nOWHRzKTIgWLo9nXfWvk6oGUAc53E5lIyzpIGZoOT8=.7f6a388a-cf48-4a5a-898d-37d847cb9d09@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Nothing further from me.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4504

From ddong at openjdk.java.net  Fri Jun 18 07:15:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 07:15:25 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v3]
In-Reply-To: <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
 <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
Message-ID: <juZ67rdmi-gAVR_j-CaFo_UysKETFfR9s9TOpBPDot0=.94647ed4-819c-49fb-b618-c2c27c93780a@github.com>

On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Denghui Dong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.
> 
> David

@dholmes-ora 
Thank you!

@tstuefe Could you help review this change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From iignatyev at openjdk.java.net  Fri Jun 18 09:59:27 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 09:59:27 GMT
Subject: [jdk17] RFR: 8268596: mark hotspot runtime/verifier tests which
 ignore external VM flags
In-Reply-To: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
References: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
Message-ID: <e9h7-rk8TfNm75jKadXTVVWFxoSNYKs6qegRIY8qRQk=.f5925452-875a-4504-beea-a1650ca2a5e6@github.com>

On Fri, 11 Jun 2021 09:09:14 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `verifier/TraceClassRes.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Misha, Harold, thank you both for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/20

From iignatyev at openjdk.java.net  Fri Jun 18 09:59:30 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 09:59:30 GMT
Subject: [jdk17] RFR: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
Message-ID: <auKeHGOcVZMnqTsNho6yFuXysprEU2eMzmIsoVgJPho=.c0f4340a-ec57-40cc-b227-e4d4e36b3276@github.com>

On Fri, 11 Jun 2021 08:31:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that removes `/othervm` from 3 `runtime/jni` tests?
> from JBS:
>> `runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java`, `checked/TestCheckedEnsureLocalCapacity.java`, and `atExit/TestAtExit.java` use `main/othervm` whereas in fact, they don't need `othervm`, and if we had CODETOOLS-7902658 implemented, they would have used `driver` mode. this RFE is to remove `/othervm`, so we at least won't waste time on creating a fresh JVM.
> 
> the patch explicitly sets `-Djava.library.path=` for the child processes so they are able to locate native libraries.
> 
> testing: `runtime/jni` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

David, Misha, thank you for your reviews!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/18

From iignatyev at openjdk.java.net  Fri Jun 18 09:59:31 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 09:59:31 GMT
Subject: [jdk17] Integrated: 8268591: a few runtime/jni tests don't need
 `/othervm`
In-Reply-To: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
References: <BX18tLw2pgrcjluAdwCMviU_AmjBzsEV9vMdKRzrD54=.85642639-4328-4636-b68f-02dd775e5d44@github.com>
Message-ID: <ueicNDlGmCecigucAby_Jnvmb0bCRj2e0VR74HksWVY=.c5b287f8-3785-4ae4-944b-421764b6ad68@github.com>

On Fri, 11 Jun 2021 08:31:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that removes `/othervm` from 3 `runtime/jni` tests?
> from JBS:
>> `runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java`, `checked/TestCheckedEnsureLocalCapacity.java`, and `atExit/TestAtExit.java` use `main/othervm` whereas in fact, they don't need `othervm`, and if we had CODETOOLS-7902658 implemented, they would have used `driver` mode. this RFE is to remove `/othervm`, so we at least won't waste time on creating a fresh JVM.
> 
> the patch explicitly sets `-Djava.library.path=` for the child processes so they are able to locate native libraries.
> 
> testing: `runtime/jni` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 59d84787
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/59d84787e91e85dba4df45e99aa376f484e6ddff
Stats:     18 lines in 3 files changed: 8 ins; 1 del; 9 mod

8268591: a few runtime/jni tests don't need `/othervm`

Reviewed-by: dholmes, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/18

From iignatyev at openjdk.java.net  Fri Jun 18 10:01:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:01:35 GMT
Subject: [jdk17] RFR: 8268599: mark hotspot runtime/sealedClasses tests
 which ignore external VM flags
In-Reply-To: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
References: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
Message-ID: <YdqZVTI_Nva6ndA5ytYA-qsPbgj8luAORwVcx21BWz4=.4c996dc5-e567-4ec7-9cdc-952dc965a4ed@github.com>

On Fri, 11 Jun 2021 09:36:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `runtime/sealedClasses` tests which ignore all external flags?
> 
> Thanks,
> -- Igor

Misha, David, thank you!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/23

From iignatyev at openjdk.java.net  Fri Jun 18 10:01:33 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:01:33 GMT
Subject: [jdk17] RFR: 8268598: mark hotspot runtime/stringtable tests
 which ignore external VM flags
In-Reply-To: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
References: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
Message-ID: <paDsqTRsBev4ddEQILGpmPyVQ2L3EY6DpM7BqeyUuAA=.82ecc259-932f-4acc-b4f0-05ac83040a56@github.com>

On Fri, 11 Jun 2021 09:17:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `stringtable/StringTableVerifyTest.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

Harold and Misha, thank you for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/22

From iignatyev at openjdk.java.net  Fri Jun 18 10:01:37 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:01:37 GMT
Subject: [jdk17] RFR: 8268601: mark hotspot runtime/records tests which
 ignore external VM flags
In-Reply-To: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
References: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
Message-ID: <KAFBSfLi5z_43IKL7h95ZkqwE4MVCRqWjzJYzXGz85M=.9ca13b6c-2822-45e8-8baa-6e60df249866@github.com>

On Fri, 11 Jun 2021 09:43:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `RedefineRecord.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

David, Misha, thanks for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/24

From iignatyev at openjdk.java.net  Fri Jun 18 10:01:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:01:38 GMT
Subject: [jdk17] Integrated: 8268601: mark hotspot runtime/records tests which
 ignore external VM flags
In-Reply-To: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
References: <NU0OYMIo4sV-vFYFsI5MGvRaFig43CuUd4gG3m1YFww=.aeb2844f-7a9d-469e-9aae-bd734f7e472c@github.com>
Message-ID: <UJkkyfMHF1yGseUMON8Zwq5_CbXMxz73RmEjH-7NxCA=.feefc553-e4d6-4c84-b20d-509f8a7fc412@github.com>

On Fri, 11 Jun 2021 09:43:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `RedefineRecord.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 8ccb76eb
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/8ccb76eb135c33349860f503745fdff49f158066
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268601: mark hotspot runtime/records tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/24

From iignatyev at openjdk.java.net  Fri Jun 18 10:02:33 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:02:33 GMT
Subject: [jdk17] RFR: 8268597: mark hotspot runtime/symboltable tests
 which ignore external VM flags
In-Reply-To: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
References: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
Message-ID: <pWKcM4fRfvwHoHIbjJiywof6UHNV33_OxOzeDy5k70c=.6711260e-a8b5-4835-b47a-f3e98e00761e@github.com>

On Fri, 11 Jun 2021 09:13:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `symboltable/ShortLivedSymbolCleanup.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

David and Misha, thank you for reviewing this.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/21

From iignatyev at openjdk.java.net  Fri Jun 18 10:02:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:02:38 GMT
Subject: [jdk17] Integrated: 8268596: mark hotspot runtime/verifier tests
 which ignore external VM flags
In-Reply-To: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
References: <9P4cqiYK1pZqVQ9YxEowXjSX7jj52_4KZEWffnEI1rE=.f1fa0f71-39ab-429a-9441-ac61e041a44d@github.com>
Message-ID: <OUXcVx6G03r3sF9GWJ8IyIHJtwcaSCYtTf6JmZijhK0=.1676fb71-ad59-4fb3-b0c9-2e60d4f02b75@github.com>

On Fri, 11 Jun 2021 09:09:14 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `verifier/TraceClassRes.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 9f4f0392
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/9f4f039231895f04bcdae4b25e1861f2070f1d8b
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268596: mark hotspot runtime/verifier tests which ignore external VM flags

Reviewed-by: hseigel, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/20

From iignatyev at openjdk.java.net  Fri Jun 18 10:02:34 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:02:34 GMT
Subject: [jdk17] Integrated: 8268597: mark hotspot runtime/symboltable tests
 which ignore external VM flags
In-Reply-To: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
References: <XNC1OowCcIkofHFZR-5ynGooNSdMrGpHpxnPQ4Yavq4=.5de2552f-42a0-4a51-ae34-172927c1c4dd@github.com>
Message-ID: <xyIWzc1--eBg48uTC-7wToNz_jE3ql8zEESSv6dC7yI=.aacf488a-fd2a-4863-888e-6fdd9221c041@github.com>

On Fri, 11 Jun 2021 09:13:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `symboltable/ShortLivedSymbolCleanup.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 4006fe73
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/4006fe735af70b01b2c254264b816fc067bfbd0d
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268597: mark hotspot runtime/symboltable tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/21

From iignatyev at openjdk.java.net  Fri Jun 18 10:03:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:03:35 GMT
Subject: [jdk17] Integrated: 8268594: runtime/handshake tests don't need
 WhiteBox after AOT removal
In-Reply-To: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
References: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
Message-ID: <P750zTqz7u0WS_zayFugJI_EwPUCUr_xWCtpQa5Q8xw=.f92d0648-877b-4952-8765-ac89a18731e1@github.com>

On Fri, 11 Jun 2021 08:45:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> `runtime/handshake/HandshakeTransitionTest.java` and `HandshakeTimeoutTest.java` use WhiteBox to check the value of `UseJVMCICompiler` as a workaround for AOT not supporting local handshakes (see [JDK-8191437](https://bugs.openjdk.java.net/browse/JDK-8191437)). 
>>
>> this isn't needed anymore and can be removed.
> 
> testing: `runtime/handshake` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 58eddc81
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/58eddc81102c233061de67a1deaa8d8fee8d5857
Stats:     26 lines in 2 files changed: 0 ins; 24 del; 2 mod

8268594: runtime/handshake tests don't need WhiteBox after AOT removal

Reviewed-by: dholmes, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/19

From iignatyev at openjdk.java.net  Fri Jun 18 10:03:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:03:35 GMT
Subject: [jdk17] RFR: 8268594: runtime/handshake tests don't need WhiteBox
 after AOT removal
In-Reply-To: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
References: <uoTaRfvr5U_jLAzipPLhXWc0EevqLfyUq9Adba4LmmM=.1da06d3f-9f63-4bf4-943d-be9d16826954@github.com>
Message-ID: <ZJT7qyRRSHmE1v_kOPaYE6EvJV0P0LQ6pVobgz0vcOE=.f2da7f4f-e0dc-45b6-8b02-adfcb6536e52@github.com>

On Fri, 11 Jun 2021 08:45:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small test-only patch?
> from JBS:
>> `runtime/handshake/HandshakeTransitionTest.java` and `HandshakeTimeoutTest.java` use WhiteBox to check the value of `UseJVMCICompiler` as a workaround for AOT not supporting local handshakes (see [JDK-8191437](https://bugs.openjdk.java.net/browse/JDK-8191437)). 
>>
>> this isn't needed anymore and can be removed.
> 
> testing: `runtime/handshake` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Misha and David, thanks!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/19

From igor.ignatyev at oracle.com  Fri Jun 18 10:05:38 2021
From: igor.ignatyev at oracle.com (Igor Ignatev)
Date: Fri, 18 Jun 2021 10:05:38 +0000
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
 <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
Message-ID: <93397EBF-4EDA-4A50-AF61-A7E2E592B9E9@oracle.com>

adding Thomas' direct email.

-- Igor
> On Jun 11, 2021, at 9:38 AM, Jie Fu <jiefu at openjdk.java.net> wrote:
> 
> On Mon, 24 May 2021 09:10:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:
> 
>>> this will, however, only solve the problem w/ the test; but I also share Thomas' [concern](https://github.com/openjdk/jdk/pull/4140#issuecomment-845836298)[*], we shouldn't need 1g (or even .5g) of heap space to eat up 20m of metaspace (even w/ small classes like `AnonkTestee01`), so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
>>> 
>>> -- Igor
>>> 
>>> [*] 
>>>> What I am concerned about is that with there should not be that much variance in how much heap space we use. Sure you can set it to 1g or 2g, but something is clearly off. I get by on Linux x64 with 128m, on 32bit x86 with 256m (since we don't have CompressedClassPointers we need somewhat more heap). But needing 1g on aarch64 seems weird.
>> 
>>> so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
>> 
>> Yes, I think that makes sense since all of our linux-aarch64 platforms couldn't reproduce the OOME except those of Oracle's .
> 
>> @DamonFool , the goal of this test is to check that in case of (nearly) exhaused metaspace defining classes via `MethodHandles.Lookup::defineHiddenClass` will lead to OOME, after your rewriting, this test doesn't serve that purpose anymore, now it just checks that runnig `java -version` w/ small metaspace will lead to OOME.
>> 
>> -- Igor
> 
> @tstuefe , do you also think we should revert this change and use `-XX:MaxRAMPercentage=25` to fix the bug?
> Thanks.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4140


From iignatyev at openjdk.java.net  Fri Jun 18 10:04:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:04:40 GMT
Subject: [jdk17] Integrated: 8268598: mark hotspot runtime/stringtable tests
 which ignore external VM flags
In-Reply-To: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
References: <CwwCRL1ac4UyXSnVJcySJ2noVLCY0dqHcIwH8m4iaEE=.27e98475-0a7e-4d0e-a447-13982aa3aaf1@github.com>
Message-ID: <skpc-a5BrFDqG06_QRPH0kd1Ey9ZdnFMi-pJ5ujf0Do=.5b97698f-26cf-4ff2-8e04-1f5be05eaf66@github.com>

On Fri, 11 Jun 2021 09:17:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `stringtable/StringTableVerifyTest.java` test as it ignores all external flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 3e1dc0a7
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/3e1dc0a7655f26ad38b5179f720eb4431bcd4cc3
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268598: mark hotspot runtime/stringtable tests which ignore external VM flags

Reviewed-by: hseigel, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/22

From iignatyev at openjdk.java.net  Fri Jun 18 10:05:31 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:05:31 GMT
Subject: [jdk17] Integrated: 8268599: mark hotspot runtime/sealedClasses tests
 which ignore external VM flags
In-Reply-To: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
References: <nm0yrd5RO51ZQdgi3vez5IcsNd4AsEvCKhB8GvC8aHM=.68c3072b-3217-42b2-9bea-902e93044ea9@github.com>
Message-ID: <R-KQrWYNJ0rcl76vnBiiHv1oom1hOwgWRdv4Dh8tjzE=.9295be4c-ac41-4405-b5a0-621482c696c8@github.com>

On Fri, 11 Jun 2021 09:36:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `runtime/sealedClasses` tests which ignore all external flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 2f65d402
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/2f65d4021f3f51a342419a61bc934863e421f952
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8268599: mark hotspot runtime/sealedClasses tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

-------------

PR: https://git.openjdk.java.net/jdk17/pull/23

From iignatyev at openjdk.java.net  Fri Jun 18 11:00:51 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 11:00:51 GMT
Subject: [jdk17] RFR: 8268612: a few runtime/memory tests don't check exit code
Message-ID: <z2TsXyxDFqfWCwSbleuXG7T-W-YYbRPTzG12q_g6qM8=.b99795c8-f5ef-45d4-b084-fbabe03a62d8@github.com>

Hi all,

could you please review this small patch that adds checks of exit code to a few `runtime/memory` tests?
from JBS:
> `ReserveMemory.java`, `ReadFromNoaccessArea.java` and `TestLargePagesFlags.java` tests spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors

in `ReadFromNoaccessArea.java`, the patch removes throwing of an exception in `DummyClassWithMainTryingToReadFromNoaccessArea` (child process), so we will get 0 as an exit code if/when we don't crash.

testing: `runtime/memory` tests on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

-------------

Commit messages:
 - 8268612

Changes: https://git.openjdk.java.net/jdk17/pull/97/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=97&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268612
  Stats: 4 lines in 3 files changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/97.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/97/head:pull/97

PR: https://git.openjdk.java.net/jdk17/pull/97

From iignatyev at openjdk.java.net  Fri Jun 18 11:07:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 11:07:40 GMT
Subject: [jdk17] RFR: 8269025: jsig/Testjsig.java doesn't check exit code
Message-ID: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>

Hi all,

could you please review this small trivial test-only change that adds a check of exit code to `jsig/Testjsig.java` test?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright
 - 8269025

Changes: https://git.openjdk.java.net/jdk17/pull/98/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=98&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269025
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/98.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/98/head:pull/98

PR: https://git.openjdk.java.net/jdk17/pull/98

From kvn at openjdk.java.net  Fri Jun 18 13:03:30 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 18 Jun 2021 13:03:30 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <a2KonMVXwFMsSdBz4mnArgYd85ARF0vjLoM5YXQJbiU=.c69e97ab-8ad4-4f69-9473-dd3158d1dd9b@github.com>

On Thu, 17 Jun 2021 15:37:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Thank you, David, for explanation.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4522

From hseigel at openjdk.java.net  Fri Jun 18 13:57:05 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 18 Jun 2021 13:57:05 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v3]
In-Reply-To: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
Message-ID: <nsf8GfmmXppb1TK9vbBl5GDtWfOPImAH7QPx4zHtnoU=.616957e7-30d0-475f-9c4a-cccbdba874be@github.com>

> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
> 
> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
> 
> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
> 
> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  add check_compatibility argument

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4497/files
  - new: https://git.openjdk.java.net/jdk/pull/4497/files/094a71a9..0d063d6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=01-02

  Stats: 134 lines in 4 files changed: 124 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4497/head:pull/4497

PR: https://git.openjdk.java.net/jdk/pull/4497

From hseigel at openjdk.java.net  Fri Jun 18 13:57:09 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 18 Jun 2021 13:57:09 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v2]
In-Reply-To: <_4uO5jsFXStidEfOTYSDKIHDw9iOQFD2UBqTUvgXUXY=.4c0f2ad4-74dc-430e-8e5e-2e685e507039@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <n-niGG-H_MiMPX3LesZYz_fmeB9HCrCUrQWkJgcrWcY=.eb27784e-5917-4107-9a39-ea3ef9c29138@github.com>
 <_4uO5jsFXStidEfOTYSDKIHDw9iOQFD2UBqTUvgXUXY=.4c0f2ad4-74dc-430e-8e5e-2e685e507039@github.com>
Message-ID: <wbP8fne9wkBPBc7o1CzPF15YOLTeBOaNcS4UhOj8xLw=.c1383d7f-85e8-4e1d-a5a6-6e4c01a79b8c@github.com>

On Thu, 17 Jun 2021 18:54:33 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comments, removed unneeded 'retur;'
>
> src/hotspot/share/classfile/classFileParser.cpp line 644:
> 
>> 642:             // Pass no_name so method name doesn't affect check for legal signature.
>> 643:             const Symbol* const no_name = vmSymbols::type_name(); // place holder
>> 644:             verify_legal_method_signature(no_name, sig, CHECK);
> 
> verify_legal_method_signature() has the potential to throw an exception.  Now it will have no name to include in that exception message concerning an illegal method signature.

Thanks Lois for finding this issue.

Please review commit 3 that restores passing the method name to verify_legal_method_signature() for use in exception messages and adds a flag parameter indicating if verify_legal_method_signature() should check if the method name and signature are compatible.

The change also adds a test case to check that the correct method name is in the exception message when verify_legal_method_signature() finds a bad method signature.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From hseigel at openjdk.java.net  Fri Jun 18 14:48:30 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 18 Jun 2021 14:48:30 GMT
Subject: [jdk17] RFR: 8269025: jsig/Testjsig.java doesn't check exit code
In-Reply-To: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>
References: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>
Message-ID: <DP346a86QU6wGF5Kd_cVMYBv_BQLIU9sykdV3FKei9Y=.1baf6360-ab78-4ce5-ab86-eb5077b9e273@github.com>

On Fri, 18 Jun 2021 11:01:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small trivial test-only change that adds a check of exit code to `jsig/Testjsig.java` test?
> 
> Thanks,
> -- Igor

Looks good and trivial.
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/98

From pchilanomate at openjdk.java.net  Fri Jun 18 15:04:32 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 15:04:32 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v2]
In-Reply-To: <6SkM2mxuRj_IXbux_5Ip5sdYc1aR-UGM-uHcma3PXM0=.f512b6e0-6ada-415d-8a93-b62a1aeb71db@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <6SkM2mxuRj_IXbux_5Ip5sdYc1aR-UGM-uHcma3PXM0=.f512b6e0-6ada-415d-8a93-b62a1aeb71db@github.com>
Message-ID: <N8sJ7dTMa9OLAb0QTsqU5KsI8vR4guKmYJXe6Zkyc4g=.dee0ab0c-76d3-472e-a729-5fa995771d1a@github.com>

On Thu, 17 Jun 2021 21:39:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove test Test8062950.java + fix commments
>>  - fix comment in vm_version_ppc.cpp
>
> src/hotspot/cpu/ppc/vm_version_ppc.cpp line 382:
> 
>> 380:   if (UseRTMLocking) {
>> 381:     // If CPU or OS do not support TM:
>> 382:     // Can't continue because UseRTMLocking affects UseBiasedLocking flag
> 
> Can you fix in previous line `TM` -> `RTM`

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 15:04:28 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 15:04:28 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v2]
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - remove test Test8062950.java + fix commments
 - fix comment in vm_version_ppc.cpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4522/files
  - new: https://git.openjdk.java.net/jdk/pull/4522/files/cba01d01..5f844d36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=00-01

  Stats: 57 lines in 3 files changed: 6 ins; 48 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 15:04:42 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 15:04:42 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v2]
In-Reply-To: <ejuXXvrKuGhExPXfVg009Ore8L80ypum2tHX58QxQVA=.2e5d0c84-7426-4ed1-b764-4a9ac241f861@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <ejuXXvrKuGhExPXfVg009Ore8L80ypum2tHX58QxQVA=.2e5d0c84-7426-4ed1-b764-4a9ac241f861@github.com>
Message-ID: <9mKT_9Ndf7h1pCC4qwLh3SZpjWmhkp_Icd3-y2kZqLI=.cb497443-0753-407b-bc7d-fe843f190a69@github.com>

On Thu, 17 Jun 2021 23:48:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove test Test8062950.java + fix commments
>>  - fix comment in vm_version_ppc.cpp
>
> src/hotspot/share/code/nmethod.hpp line 281:
> 
>> 279:   nmethod(Method* method,
>> 280:           CompilerType type,
>> 281:           int nmethod_size,
> 
> Not obvious that this entire comment is no longer relevant. The basic description of the use of the offsets seems applicable even if not actually needed for revoking the bias.

Fixed. I restored most of the comment but remove the biased locking references.

> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java line 156:
> 
>> 154:     long prototypeMarkWord() {
>> 155:         return markWordNoHashInPlace | markWordNoLockInPlace;
>> 156:     }
> 
> It is not immediately obvious that this is correct for all object types. Does this match what the initial_mark() is now?

Yes, with biased locking gone there is now only one prototype for the markword. This should match markWord::prototype().

> test/hotspot/jtreg/compiler/c2/Test8062950.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> I'd argue this test serves no purpose now.

Right, removed.

> test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java line 65:
> 
>> 63:                 // Inflate locks[handshakee] if possible
>> 64:                 System.identityHashCode(locks[handshakee]);
>> 65:                 walked = wb.handshakeReadMonitors(workingThreads[handshakee]);
> 
> It is not at all obvious that this revised test and the new WB routine actually test what was previously being tested. Do we actually need to involve monitors here or is that just something that has been picked to examine while in a handshake?

So the purpose of this test was to exercise direct handshakes between threads. Back then I used biased locking because it was the only one that was using them (and I didn't thought about using whitebox). Since the test has proven to be good to uncover some bugs I tried to keep the same elements. Walking the stack looking for monitors is one. Then I added System.identityHashCode() to force transitions from stack-locked to inflated whenever possible so that we also change the state of the lock as we did with biased locking (from biased to stack-locked).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 15:06:13 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 15:06:13 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <aAG8XSz0r53UJt8zjXa4Z5bgcE5ouNORDOVLiq9wFU4=.c2ab5f95-288c-4b2b-9d00-02376f634c6e@github.com>

On Thu, 17 Jun 2021 15:37:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Thanks for the reviews Vladimir and David!

Patricio

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From iignatyev at openjdk.java.net  Fri Jun 18 15:28:34 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 15:28:34 GMT
Subject: [jdk17] RFR: 8269025: jsig/Testjsig.java doesn't check exit code
In-Reply-To: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>
References: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>
Message-ID: <kSgmruuOMXicsc4_wn1LeUH0v5aDf7C9eQ6_mtlZCec=.ec783746-2905-4bf4-9232-7e26c423b7af@github.com>

On Fri, 18 Jun 2021 11:01:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small trivial test-only change that adds a check of exit code to `jsig/Testjsig.java` test?
> 
> Thanks,
> -- Igor

Thank you, Harold.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/98

From iignatyev at openjdk.java.net  Fri Jun 18 15:28:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 15:28:35 GMT
Subject: [jdk17] Integrated: 8269025: jsig/Testjsig.java doesn't check exit
 code
In-Reply-To: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>
References: <QZfDVbyoLO3d_-24AnlDjUX5fCnTWXWpiBkrvBw1HTY=.189f4a15-d36f-4ba3-9437-a51fc4a4ca26@github.com>
Message-ID: <t2SNSx9Hl_RJCPVb8k2pwv7GAG2gnYEU8vWrlLpqvOY=.f982bc68-4923-456a-893b-450d26060bfc@github.com>

On Fri, 18 Jun 2021 11:01:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small trivial test-only change that adds a check of exit code to `jsig/Testjsig.java` test?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 60389eed
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/60389eedb3c9932de57aca740a8116db83302ffa
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8269025: jsig/Testjsig.java doesn't check exit code

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/jdk17/pull/98

From dcubed at openjdk.java.net  Fri Jun 18 16:40:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Jun 2021 16:40:50 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v2]
In-Reply-To: <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
Message-ID: <ajaeLNuSWFs-2xJpXhiQZYV2EzLGi2jJSYjNyGTFv0A=.582ccdc7-0318-405e-a242-693a9fccf4b5@github.com>

On Fri, 18 Jun 2021 15:04:28 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test Test8062950.java + fix commments
>  - fix comment in vm_version_ppc.cpp

Wow! 163 files touched... Biased Locking was certainly more wide
spread than I imagined/remembered.

Thumbs up! I only spotted very minor nits.

Thanks for persisting on this patch. Keeping it up to date over a
couple of release is hard with a 163 file footprint...

src/hotspot/cpu/arm/arm.ad line 5457:

> 5455:     __ b(loop, eq);
> 5456:     __ teq($tmp$$Register, 0);
> 5457:     __ membar(MacroAssembler::Membar_mask_bits(MacroAssembler::LoadStore | MacroAssembler::LoadLoad), noreg);

Does the comment you deleted mean that storeXConditional() is only used
by biased locking or that only biased locking's use of storeXConditional() is
the only caller that needed the membar?

src/hotspot/cpu/arm/vm_version_arm_32.cpp line 362:

> 360:   // Therefore the Biased Locking is enabled on ARMv5 and ARM MP only.
> 361:   //
> 362:   return (!os::is_MP() && (arm_arch() > 5)) ? false : true;

Wow. The gory details are amazing...

src/hotspot/cpu/ppc/ppc.ad line 12140:

> 12138:                                  _rtm_counters, _stack_rtm_counters,
> 12139:                                  ((Method*)(ra_->C->method()->constant_encoding()))->method_data(),
> 12140:                                  /*TM*/ true, ra_->C->profile_rtm());

Not your bug, but that "TM" should be "RTM".

src/hotspot/cpu/ppc/ppc.ad line 12174:

> 12172:     __ compiler_fast_unlock_object($crx$$CondRegister, $oop$$Register, $box$$Register,
> 12173:                                    $tmp1$$Register, $tmp2$$Register, $tmp3$$Register,
> 12174:                                    /*TM*/ true);

Not your bug, but that "TM" should be "RTM".

src/hotspot/cpu/x86/templateTable_x86.cpp line 4026:

> 4024:     // initialize object header only.
> 4025:     __ bind(initialize_header);
> 4026:     __ movptr(Address(rax, oopDesc::mark_offset_in_bytes ()),

Not your bug, but can you delete the space before `()`?

src/hotspot/share/runtime/deoptimization.cpp line 1440:

> 1438:           if (mark.has_locker() && fr.sp() > (intptr_t*)mark.locker()) {
> 1439:             // With exec_mode == Unpack_none obj may be thread local and locked in
> 1440:             // a callee frame. // Make the lock in the callee a recursive lock and restore the displaced header.

Please delete the embedded `//`.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4522

From cjplummer at openjdk.java.net  Fri Jun 18 18:15:36 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 18 Jun 2021 18:15:36 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v2]
In-Reply-To: <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
Message-ID: <kb69l1jWmgJXpnPQZ3R17Satbd1eDhdYkgXIANPPdGY=.f6669e38-642d-497e-bc8f-2cc45e17cf93@github.com>

On Fri, 18 Jun 2021 15:04:28 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test Test8062950.java + fix commments
>  - fix comment in vm_version_ppc.cpp

test/jdk/com/sun/jdi/EATests.java line 52:

> 50:  *                 -XX:+WhiteBoxAPI
> 51:  *                 -Xbatch
> 52:  *                 -XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:-EliminateLocks -XX:+EliminateNestedLocks -XX:+UseBiasedLocking -XX:-UseOptoBiasInlining

I don't see this combination of flags in the new diff. I think the approach should be to remove the biased locking flags, and then remove any duplicate test runs that result from doing that.

test/jdk/com/sun/jdi/EATests.java line 235:

> 233:         // Relocking test cases
> 234:         new EARelockingSimpleTarget()                                                       .run();
> 235:         new EARelockingSimple_2Target()                                                     .run();

I know all the tests that were removed mention biased locking in the comments, but do they require biased locking to function properly? I'm just wondering if we might get better EA test coverage if they are left in place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 18:59:32 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 18:59:32 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v3]
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <_-xnCSNtYtcahG9u3XdGmXBkDOMJFx0pSgTw8KJmd7U=.b295c374-e99e-4d3b-9e14-83935a1ea1dd@github.com>

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Dan's comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4522/files
  - new: https://git.openjdk.java.net/jdk/pull/4522/files/5f844d36..cb3b5e22

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=01-02

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 18:59:43 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 18:59:43 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v2]
In-Reply-To: <ajaeLNuSWFs-2xJpXhiQZYV2EzLGi2jJSYjNyGTFv0A=.582ccdc7-0318-405e-a242-693a9fccf4b5@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
 <ajaeLNuSWFs-2xJpXhiQZYV2EzLGi2jJSYjNyGTFv0A=.582ccdc7-0318-405e-a242-693a9fccf4b5@github.com>
Message-ID: <9MAr08guijfyHDWKY9z_brRhegZz_N1u0gAGklZIwFU=.840ced6d-01db-4679-8e86-d78392017e50@github.com>

On Fri, 18 Jun 2021 15:34:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove test Test8062950.java + fix commments
>>  - fix comment in vm_version_ppc.cpp
>
> src/hotspot/cpu/arm/arm.ad line 5457:
> 
>> 5455:     __ b(loop, eq);
>> 5456:     __ teq($tmp$$Register, 0);
>> 5457:     __ membar(MacroAssembler::Membar_mask_bits(MacroAssembler::LoadStore | MacroAssembler::LoadLoad), noreg);
> 
> Does the comment you deleted mean that storeXConditional() is only used
> by biased locking or that only biased locking's use of storeXConditional() is
> the only caller that needed the membar?

If I grep for "new StoreIConditional" I don't find anything, same with StoreLConditional so it seems they are not used outside of biased locking (?). StoreIConditional was actually introduced for biased locking (6462850). I searched back in history and StoreLConditional appears first in opto/classes.hpp in 2002. Maybe @vnkozlov could confirm if we should keep them or remove them?

> src/hotspot/cpu/ppc/ppc.ad line 12140:
> 
>> 12138:                                  _rtm_counters, _stack_rtm_counters,
>> 12139:                                  ((Method*)(ra_->C->method()->constant_encoding()))->method_data(),
>> 12140:                                  /*TM*/ true, ra_->C->profile_rtm());
> 
> Not your bug, but that "TM" should be "RTM".

Fixed.

> src/hotspot/cpu/ppc/ppc.ad line 12174:
> 
>> 12172:     __ compiler_fast_unlock_object($crx$$CondRegister, $oop$$Register, $box$$Register,
>> 12173:                                    $tmp1$$Register, $tmp2$$Register, $tmp3$$Register,
>> 12174:                                    /*TM*/ true);
> 
> Not your bug, but that "TM" should be "RTM".

Fixed.

> src/hotspot/cpu/x86/templateTable_x86.cpp line 4026:
> 
>> 4024:     // initialize object header only.
>> 4025:     __ bind(initialize_header);
>> 4026:     __ movptr(Address(rax, oopDesc::mark_offset_in_bytes ()),
> 
> Not your bug, but can you delete the space before `()`?

Fixed.

> src/hotspot/share/runtime/deoptimization.cpp line 1440:
> 
>> 1438:           if (mark.has_locker() && fr.sp() > (intptr_t*)mark.locker()) {
>> 1439:             // With exec_mode == Unpack_none obj may be thread local and locked in
>> 1440:             // a callee frame. // Make the lock in the callee a recursive lock and restore the displaced header.
> 
> Please delete the embedded `//`.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From dcubed at openjdk.java.net  Fri Jun 18 19:11:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Jun 2021 19:11:46 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v3]
In-Reply-To: <_-xnCSNtYtcahG9u3XdGmXBkDOMJFx0pSgTw8KJmd7U=.b295c374-e99e-4d3b-9e14-83935a1ea1dd@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <_-xnCSNtYtcahG9u3XdGmXBkDOMJFx0pSgTw8KJmd7U=.b295c374-e99e-4d3b-9e14-83935a1ea1dd@github.com>
Message-ID: <UWBlpPAlBKg_srRMOCOMmFc4cPxpkivnh53296DpR6Y=.1dcf558c-e253-4e30-82fb-debdf3c7b4d6@github.com>

On Fri, 18 Jun 2021 18:59:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dan's comments

Re-reviewed the v02 incremental webrev.
Still thumbs up!

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 19:23:26 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 19:23:26 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v3]
In-Reply-To: <UWBlpPAlBKg_srRMOCOMmFc4cPxpkivnh53296DpR6Y=.1dcf558c-e253-4e30-82fb-debdf3c7b4d6@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <_-xnCSNtYtcahG9u3XdGmXBkDOMJFx0pSgTw8KJmd7U=.b295c374-e99e-4d3b-9e14-83935a1ea1dd@github.com>
 <UWBlpPAlBKg_srRMOCOMmFc4cPxpkivnh53296DpR6Y=.1dcf558c-e253-4e30-82fb-debdf3c7b4d6@github.com>
Message-ID: <ze26I-G0C6b79BysgZkqimGyuhMcdya5RfJsjUMhzNI=.35369551-0cd4-4eac-b6db-5a106c536ba7@github.com>

On Fri, 18 Jun 2021 19:08:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Re-reviewed the v02 incremental webrev.
> Still thumbs up!
Thanks for the review Dan!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 19:23:25 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 19:23:25 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  restore run in EATests.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4522/files
  - new: https://git.openjdk.java.net/jdk/pull/4522/files/cb3b5e22..215e46b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=02-03

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Fri Jun 18 19:23:31 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 18 Jun 2021 19:23:31 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <kb69l1jWmgJXpnPQZ3R17Satbd1eDhdYkgXIANPPdGY=.f6669e38-642d-497e-bc8f-2cc45e17cf93@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
 <kb69l1jWmgJXpnPQZ3R17Satbd1eDhdYkgXIANPPdGY=.f6669e38-642d-497e-bc8f-2cc45e17cf93@github.com>
Message-ID: <7Kh5bbLKYK3eeJKt5zDWevHMRlSSmVryy3OuCBHZvIQ=.155672c0-cf1e-4258-bfd2-489bd6aa7058@github.com>

On Fri, 18 Jun 2021 18:00:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore run in EATests.java
>
> test/jdk/com/sun/jdi/EATests.java line 52:
> 
>> 50:  *                 -XX:+WhiteBoxAPI
>> 51:  *                 -Xbatch
>> 52:  *                 -XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:-EliminateLocks -XX:+EliminateNestedLocks -XX:+UseBiasedLocking -XX:-UseOptoBiasInlining
> 
> I don't see this combination of flags in the new diff. I think the approach should be to remove the biased locking flags, and then remove any duplicate test runs that result from doing that.

Sorry I restored that run. I must have confused the +/- with the previous one.

> test/jdk/com/sun/jdi/EATests.java line 235:
> 
>> 233:         // Relocking test cases
>> 234:         new EARelockingSimpleTarget()                                                       .run();
>> 235:         new EARelockingSimple_2Target()                                                     .run();
> 
> I know all the tests that were removed mention biased locking in the comments, but do they require biased locking to function properly? I'm just wondering if we might get better EA test coverage if they are left in place.

They are trying to exercise some biased locking specific paths, but maybe @reinrich can comment on wether it is worth keeping them since he wrote the tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From xliu at openjdk.java.net  Fri Jun 18 20:17:53 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 18 Jun 2021 20:17:53 GMT
Subject: [jdk17] RFR: 8268638: semaphores of AsyncLogWriter may be broken when
 JVM is exiting.
Message-ID: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Reviewed-by: dholmes, phh
Backport-Of: fa3b44d43811dca8c609d6c61a58680835abf8e3

-------------

Commit messages:
 - Backport fa3b44d43811dca8c609d6c61a58680835abf8e3

Changes: https://git.openjdk.java.net/jdk17/pull/95/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=95&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268638
  Stats: 22 lines in 2 files changed: 6 ins; 7 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/95.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/95/head:pull/95

PR: https://git.openjdk.java.net/jdk17/pull/95

From xliu at openjdk.java.net  Fri Jun 18 20:17:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 18 Jun 2021 20:17:54 GMT
Subject: [jdk17] RFR: 8268638: semaphores of AsyncLogWriter may be broken
 when JVM is exiting.
In-Reply-To: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>
References: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>
Message-ID: <hVbajyyq0JAYjaQ3BhM9Lz8iZZvMktgsJKYXHqiMfJw=.ed417abe-05d1-48fd-ac74-f5b419f368fb@github.com>

On Fri, 18 Jun 2021 00:56:46 GMT, Xin Liu <xliu at openjdk.org> wrote:

> 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
> 
> Reviewed-by: dholmes, phh
> Backport-Of: fa3b44d43811dca8c609d6c61a58680835abf8e3

A backport task JDK-8268977 is now open, but this PR is associated with JDK-8268638.
Should I remove JDK-8268638 and add JDK-8268977?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/95

From dcubed at openjdk.java.net  Fri Jun 18 20:29:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Jun 2021 20:29:31 GMT
Subject: [jdk17] RFR: 8268638: semaphores of AsyncLogWriter may be broken
 when JVM is exiting.
In-Reply-To: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>
References: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>
Message-ID: <n_G4twFezbxJEC9iW2xj8FEwtG7aVxLkIaePgYdnPB8=.259c4c8a-44cf-43ef-a823-c01a8f8616b9@github.com>

On Fri, 18 Jun 2021 00:56:46 GMT, Xin Liu <xliu at openjdk.org> wrote:

> 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
> 
> Reviewed-by: dholmes, phh
> Backport-Of: fa3b44d43811dca8c609d6c61a58680835abf8e3

Leave this PR associated with the main bug (JDK-8268638). When you
integrate, the integration process will use the open backport bug for '17'
(JDK-8268977) for adding the changeset notification and marking the bug
as fixed in 'master' for '17':

When the bug is integrated in '17', the changeset will use:

    8268638 semaphores of AsyncLogWriter may be broken when JVM is exiting.

in the commit (which is the proper bug ID).

Since this is a 'clean' 'backport', you don't need anyone to approve and you
should be able to '/integrate' when you ready.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/95

From xliu at openjdk.java.net  Fri Jun 18 21:33:36 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 18 Jun 2021 21:33:36 GMT
Subject: [jdk17] Integrated: 8268638: semaphores of AsyncLogWriter may be
 broken when JVM is exiting.
In-Reply-To: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>
References: <NWuMXbwFjwOcbGkJprF7hcQWUU1wiZUheJw6jNGyLK0=.cb397979-c6b4-4ce0-a2a0-59080c6374a2@github.com>
Message-ID: <bFAvVT72WvZZ-1ou2R0ePUt2f_AhtcdKOKWQ0dmxdfU=.8bea20e3-235d-446c-bcd9-13fec6f21e66@github.com>

On Fri, 18 Jun 2021 00:56:46 GMT, Xin Liu <xliu at openjdk.org> wrote:

> 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
> 
> Reviewed-by: dholmes, phh
> Backport-Of: fa3b44d43811dca8c609d6c61a58680835abf8e3

This pull request has now been integrated.

Changeset: b9d73376
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/b9d7337697bd1aa5581b1a28efb3a78c221f6592
Stats:     22 lines in 2 files changed: 6 ins; 7 del; 9 mod

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Backport-of: fa3b44d43811dca8c609d6c61a58680835abf8e3

-------------

PR: https://git.openjdk.java.net/jdk17/pull/95

From stuefe at openjdk.java.net  Sun Jun 20 08:29:30 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sun, 20 Jun 2021 08:29:30 GMT
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
 <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
Message-ID: <GOrQwVWnKB2iJQ28IGn8youx9U2ybv3-QYkleK1Or38=.f62c6c5f-be22-4574-b8b6-6b67a7fa35b9@github.com>

On Fri, 11 Jun 2021 06:35:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
>> 
>> Yes, I think that makes sense since all of our linux-aarch64 platforms couldn't reproduce the OOME except those of Oracle's .
>
>> @DamonFool , the goal of this test is to check that in case of (nearly) exhaused metaspace defining classes via `MethodHandles.Lookup::defineHiddenClass` will lead to OOME, after your rewriting, this test doesn't serve that purpose anymore, now it just checks that runnig `java -version` w/ small metaspace will lead to OOME.
>> 
>> -- Igor
> 
> @tstuefe , do you also think we should revert this change and use `-XX:MaxRAMPercentage=25` to fix the bug?
> Thanks.

@DamonFool @iignatev guys, sorry for the late response. I am fine with restoring the test, I think Igor was right. 

I would love to understand the differences with aarch64s high heap usage though. Some thoughts. Do we manage on aarch64 to load the same amount of classes before OOME hits? Less? More? Does the way we create classes on aarch64 need somehow more java heap space?

It would be nice to compare metaspace state between "normal" platforms and aarch64 at the time oome hits. One way to do this would be to run the tests with -`XX:+PrintMetaspaceStatisticsAtExit` and compare the results. It would also be nice to know how many classes had been loaded at that point.

I'd be happy to take a look if someone does the tests. Unfortunately, I have no hardware to reproduce this problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140

From jiefu at openjdk.java.net  Sun Jun 20 09:08:34 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 20 Jun 2021 09:08:34 GMT
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <GOrQwVWnKB2iJQ28IGn8youx9U2ybv3-QYkleK1Or38=.f62c6c5f-be22-4574-b8b6-6b67a7fa35b9@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
 <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
 <GOrQwVWnKB2iJQ28IGn8youx9U2ybv3-QYkleK1Or38=.f62c6c5f-be22-4574-b8b6-6b67a7fa35b9@github.com>
Message-ID: <LUwtOjOsucFvYNqKVGft5xLg8oKyAVG8MfiRrnzpFt0=.8b583fb2-7402-47e2-9ce7-6578824c7f46@github.com>

On Sun, 20 Jun 2021 08:26:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I am fine with restoring the test, I think Igor was right.

OK.
Filed: https://bugs.openjdk.java.net/browse/JDK-8269065
I'd like to get it fixed in jdk17.
Thanks.

We also can't reproduce the OOME on our aarch64 platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140

From stuefe at openjdk.java.net  Sun Jun 20 09:43:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sun, 20 Jun 2021 09:43:32 GMT
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <LUwtOjOsucFvYNqKVGft5xLg8oKyAVG8MfiRrnzpFt0=.8b583fb2-7402-47e2-9ce7-6578824c7f46@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
 <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
 <GOrQwVWnKB2iJQ28IGn8youx9U2ybv3-QYkleK1Or38=.f62c6c5f-be22-4574-b8b6-6b67a7fa35b9@github.com>
 <LUwtOjOsucFvYNqKVGft5xLg8oKyAVG8MfiRrnzpFt0=.8b583fb2-7402-47e2-9ce7-6578824c7f46@github.com>
Message-ID: <ZsyEqLV2RMz_D4QP9urhTy4WyGED--Am3Hv6mMBM4Xs=.f3ae5da9-8ce3-498c-a7cd-8aecb078d5d0@github.com>

On Sun, 20 Jun 2021 09:05:36 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > I am fine with restoring the test, I think Igor was right.
> 
> OK.
> Filed: https://bugs.openjdk.java.net/browse/JDK-8269065
> I'd like to get it fixed in jdk17.
> Thanks.
> 
> We also can't reproduce the OOME on our aarch64 platforms.

Wrote offlist to you and Igor on Friday, but your mail bounced. One thing which may be a difference - and this is just a wild guess - is that Oracle's aarch64 machines use 64k pages. We recently had errors which only were reproducable on their machines due to that fact. I am not totally clear how this could cause the error, but that is the only difference I can think off off-hand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140

From jiefu at openjdk.java.net  Sun Jun 20 10:11:30 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 20 Jun 2021 10:11:30 GMT
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <ZsyEqLV2RMz_D4QP9urhTy4WyGED--Am3Hv6mMBM4Xs=.f3ae5da9-8ce3-498c-a7cd-8aecb078d5d0@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
 <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
 <GOrQwVWnKB2iJQ28IGn8youx9U2ybv3-QYkleK1Or38=.f62c6c5f-be22-4574-b8b6-6b67a7fa35b9@github.com>
 <LUwtOjOsucFvYNqKVGft5xLg8oKyAVG8MfiRrnzpFt0=.8b583fb2-7402-47e2-9ce7-6578824c7f46@github.com>
 <ZsyEqLV2RMz_D4QP9urhTy4WyGED--Am3Hv6mMBM4Xs=.f3ae5da9-8ce3-498c-a7cd-8aecb078d5d0@github.com>
Message-ID: <MQlqKwHsNGAhGnEKIG7gMje3Z1XoUtfBJgp1WPdRizo=.013c78b4-35f6-4743-8a80-ef9abb6e32c7@github.com>

On Sun, 20 Jun 2021 09:39:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> One thing which may be a difference - and this is just a wild guess - is that Oracle's aarch64 machines use 64k pages. We recently had errors which only were reproducable on their machines due to that fact. I am not totally clear how this could cause the error, but that is the only difference I can think off off-hand.

I checked one aarch64 machine:

# getconf PAGE_SIZE
65536


But I didn't reproduce the OOME on it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140

From jiefu at openjdk.java.net  Sun Jun 20 10:19:34 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 20 Jun 2021 10:19:34 GMT
Subject: RFR: 8267404:
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError [v3]
In-Reply-To: <ZsyEqLV2RMz_D4QP9urhTy4WyGED--Am3Hv6mMBM4Xs=.f3ae5da9-8ce3-498c-a7cd-8aecb078d5d0@github.com>
References: <Ppg0cBo08ZGS7RANQtjoA2syMDicgYORdNca8eI0juQ=.b48cb64a-e95a-4185-b197-c5f80163fc3f@github.com>
 <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com>
 <vIzW2ZwQCARMUmS9s1sGkeUj1i1Ws4Gb2dpz4CoD4Tg=.e8c1317d-455f-4a56-8d31-9eff3456d4f9@github.com>
 <QVoPjeQSy4GvcfCMZdJs5aPlDIXgO2peMC5a-xwD-RM=.8f64fd71-9ce5-4537-842c-0ef1e5ed996c@github.com>
 <BhtJUIS8GLqO0Lh3dfxBjnTLmsEyEGAXbjGcPajgWKQ=.bb80f30c-0fc8-4387-b356-e87fd81a3a11@github.com>
 <GOrQwVWnKB2iJQ28IGn8youx9U2ybv3-QYkleK1Or38=.f62c6c5f-be22-4574-b8b6-6b67a7fa35b9@github.com>
 <LUwtOjOsucFvYNqKVGft5xLg8oKyAVG8MfiRrnzpFt0=.8b583fb2-7402-47e2-9ce7-6578824c7f46@github.com>
 <ZsyEqLV2RMz_D4QP9urhTy4WyGED--Am3Hv6mMBM4Xs=.f3ae5da9-8ce3-498c-a7cd-8aecb078d5d0@github.com>
Message-ID: <7OXnEVdUWqKTEHdKYWyiTgdX3WzphyP5yqq3pg9sNxM=.0b8bb5a4-82cf-42d9-81b2-00f4cca3d0ce@github.com>

On Sun, 20 Jun 2021 09:39:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Filed: https://bugs.openjdk.java.net/browse/JDK-8269065
> I'd like to get it fixed in jdk17.

PR: https://github.com/openjdk/jdk17/pull/104
@iignatev @tstuefe 
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140

From jiefu at openjdk.java.net  Sun Jun 20 12:00:44 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 20 Jun 2021 12:00:44 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
Message-ID: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>

Hi all,

Please review this patch which:
 1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
 2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`

Testing:
  - Linux/x64, MacOS/x64

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8269065: [REDO] vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError

Changes: https://git.openjdk.java.net/jdk17/pull/104/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=104&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269065
  Stats: 56 lines in 1 file changed: 38 ins; 6 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/104/head:pull/104

PR: https://git.openjdk.java.net/jdk17/pull/104

From iignatyev at openjdk.java.net  Sun Jun 20 12:57:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sun, 20 Jun 2021 12:57:56 GMT
Subject: [jdk17] RFR: 8269037: jsig/Testjsig.java doesn't have to be
 restricted to linux only
Message-ID: <qldZIqOSUVRlh1MUQEktviV8bxdqQjJQ4fXBbxxZ3Xc=.dc550af3-1e2c-4788-ac3d-284dea38a6f2@github.com>

Hi all,

could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows?
from JBS:
> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is resticted to linux only, howere there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX.

testing:  `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64`


Thanks,
-- Igor

-------------

Commit messages:
 - 8269037

Changes: https://git.openjdk.java.net/jdk17/pull/105/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=105&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269037
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/105.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/105/head:pull/105

PR: https://git.openjdk.java.net/jdk17/pull/105

From aph at openjdk.java.net  Sun Jun 20 14:15:34 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 20 Jun 2021 14:15:34 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
Message-ID: <vHsCkHlzcON-tD9tV2jyGdvD11k9vcttFcjOD2QD5eA=.d327144a-2165-4679-b097-4946ead99149@github.com>

On Fri, 18 Jun 2021 19:23:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore run in EATests.java

AArch64 changes look good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From xxinliu at amazon.com  Sun Jun 20 20:50:03 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Sun, 20 Jun 2021 13:50:03 -0700
Subject: A question about memory order on x86_64
Message-ID: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>

Hi, Hotspot experts,

I am debugging a PR which uses lock-free programming. David Holmes
helped me submit this patch to the internal regression infra(thanks a
lot). We got intermittent failures at tier4~7. There are two distinct
crash sights, but they're similar. I guess the reason is asynclog thread
observed different memory state from other threads.

https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283

I have spent a lot efforts on reproducing this problem. Eventually, I
got a crash in docker and luckily coredump file and hs_err report were
all saved.

In core dump file, I see this stacktraces in asynclog thread.

(gdb) bt
...
#24 0x00007f76e1ab0e90 in flockfile () from /lib64/libc.so.6
#25 0x00007f76e3d0c253 in FileLocker (file=0xbabababababababa,
this=<synthetic pointer>) at
/jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
#26 LogFileStreamOutput::write (this=0x55ea4d504bd0, decorations=...,
msg=0x7f7624079b00 "ConcurrentLogsite 3 emits a log") at
/jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
#27 0x00007f76e3d0b572 in LogFileOutput::write_blocking
(this=0x55ea4d504bd0, decorations=..., msg=0x7f7624079b00
"ConcurrentLogsite 3 emits a log") at
/jdk/src/hotspot/share/logging/logFileOutput.cpp:308
#28 0x00007f76e3d05bbd in write (this=0x55ea4d2e1af0) at
/jdk/src/hotspot/share/logging/logAsyncWriter.hpp:106
#29 AsyncLogWriter::run (this=0x55ea4d2e1af0) at
/jdk/src/hotspot/share/logging/logAsyncWriter.cpp:163
#30 0x00007f76e44696a0 in Thread::call_run (this=0x55ea4d2e1af0) at
/jdk/src/hotspot/share/runtime/thread.cpp:394
#31 0x00007f76e3fdf9b4 in thread_native_entry (thread=0x55ea4d2e1af0) at
/jdk/src/hotspot/os/linux/os_linux.cpp:720
#32 0x00007f76e162cea5 in start_thread () from /lib64/libpthread.so.0
#33 0x00007f76e1b439fd in clone () from /lib64/libc.so.6

The corresponding code is here. _stream is 0xbabababababababa?

int LogFileStreamOutput::write(const LogDecorations& decorations, const
char* msg) {
  const bool use_decorations = !_decorators.is_empty();

  int written = 0;
  FileLocker flocker(_stream);
  if (use_decorations)

Here is the relevant disassembly code.
...prolog
0x7f76e3d0c223 <LogFileStreamOutput::write(LogDecorations const&, char
const*)+19>      mov    %rdi,%rbx
0x7f76e3d0c226 <LogFileStreamOutput::write(LogDecorations const&, char
const*)+22>      sub    $0x128,%rsp
0x7f76e3d0c22d <LogFileStreamOutput::write(LogDecorations const&, char
const*)+29>      mov    0x28(%rdi),%r15
0x7f76e3d0c231 <LogFileStreamOutput::write(LogDecorations const&, char
const*)+33>      mov    0x20(%rdi),%r12d
0x7f76e3d0c235 <LogFileStreamOutput::write(LogDecorations const&, char
const*)+37>      mov    %rdx,-0x148(%rbp)
0x7f76e3d0c23c <LogFileStreamOutput::write(LogDecorations const&, char
const*)+44>      mov    %r15,%rdi
0x7f76e3d0c23f <LogFileStreamOutput::write(LogDecorations const&, char
const*)+47>      mov    %fs:0x28,%rax
0x7f76e3d0c248 <LogFileStreamOutput::write(LogDecorations const&, char
const*)+56>      mov    %rax,-0x38(%rbp)
0x7f76e3d0c24c <LogFileStreamOutput::write(LogDecorations const&, char
const*)+60>      xor    %eax,%eax
0x7f76e3d0c24e <LogFileStreamOutput::write(LogDecorations const&, char
const*)+62>      callq  0x7f76e3feb090 <os::flockfile(_IO_FILE*)>
0x7f76e3d0c253 <LogFileStreamOutput::write(LogDecorations const&, char
const*)+67>      test   %r12d,%r12d


We can see that r15 = load 0x28(%rdi) and its value is bad. however, in
memory, Its value is correct. this->_stream is 0x55ea4d0f8d00.

(gdb) p /x $r15
$13 = 0xbabababababababa

(gdb) p /x $rbx
$27 = 0x55ea4d504bd0

(gdb) x /1g $rbx + 0x28
0x55ea4d504bf8: 0x000055ea4d0f8d00

In main thread, we can see that output->_stream is well defined.

(gdb) p output
$24 = (LogOutput *) 0x55ea4d504bd0

(gdb) p ((LogFileOutput*)output)->_stream
$23 = (FILE *) 0x55ea4d0f8d00


-------------------------------------------------------------------------

Can I say it's a memory ordering issue on x86_64? TBH, I can't explain
how that happens.

Early moment in main thread, LogFileOutput::initialize() was called and
_stream was initialized. After then, the program at least has gone through:

1. Atomic::add (lock prefix instruction, which is implied store-load
barrier?).
2. sem_wait/post (acquire-release semantics).

Therefore, I believe the current thread must see the written value of
LogFileOutput::initialize(). ie. _stream should be (FILE *)
0x55ea4d0f8d00, not 0xbababa...

Last but not least question. To further understand this problem and
verify patch, I think the key is to find a reproducible. Any thoughts on
how to reproduce this kinda of problem?  So far, I only came across this
crash once on my side. I used a docker image of Oracle Linux 7.9 (glibc
2.17) with cpuset 0~2.  Beside a core dump and a crash report, I can't
reproduce it anymore. I think I must overlook some important factors
here.  Really appreciate some head-ups.

I notice that Oracle is using 3-gen Zen architecture to run tests. Is it
anything different from conventional x86_64? In AMD's manual[1], 7.4.2,
Table-3, here is the description about lock-prefix instruction.

k  ? All loads and stores associated with the I/O and locked
instructions complete to memory (no bufferedstores) before a load or
store from a subsequent instruction is issued.

It seems to me that it doesn't imply "bidirectional full memory barrier"
or storeload barrier. it just has acquire semantic. I read the story
behind this change and Aleksey's article[2]. I'm just not sure the
following code is equivalent to "mfence" on EPYC machines because AMD's
manual is different from Intel's.

inline void OrderAccess::fence() {
   // always use locked addl since mfence is sometimes expensive
#ifdef AMD64
  __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
#else
  __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
#endif
  compiler_barrier();
}


[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2]
https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1

thanks,
--lx




From rrich at openjdk.java.net  Sun Jun 20 23:08:31 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sun, 20 Jun 2021 23:08:31 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <7Kh5bbLKYK3eeJKt5zDWevHMRlSSmVryy3OuCBHZvIQ=.155672c0-cf1e-4258-bfd2-489bd6aa7058@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <p7aofGjZMelVsgf-dIafkQU51lu9uA4IF50NwqXfpMA=.faaceed7-c8f9-46cf-b7a8-f2577b215e9d@github.com>
 <kb69l1jWmgJXpnPQZ3R17Satbd1eDhdYkgXIANPPdGY=.f6669e38-642d-497e-bc8f-2cc45e17cf93@github.com>
 <7Kh5bbLKYK3eeJKt5zDWevHMRlSSmVryy3OuCBHZvIQ=.155672c0-cf1e-4258-bfd2-489bd6aa7058@github.com>
Message-ID: <ozHz5nLui6YyudWgwHNveIc2TxDjiC9qVGzvcMZDT4U=.085d9810-70e7-486d-a519-f018f6b311d7@github.com>

On Fri, 18 Jun 2021 19:19:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/EATests.java line 235:
>> 
>>> 233:         // Relocking test cases
>>> 234:         new EARelockingSimpleTarget()                                                       .run();
>>> 235:         new EARelockingSimple_2Target()                                                     .run();
>> 
>> I know all the tests that were removed mention biased locking in the comments, but do they require biased locking to function properly? I'm just wondering if we might get better EA test coverage if they are left in place.
>
> They are trying to exercise some biased locking specific paths, but maybe @reinrich can comment on wether it is worth keeping them since he wrote the tests.

The test cases are very specific to biased locking. It is not worth keeping them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From rrich at openjdk.java.net  Sun Jun 20 23:27:37 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sun, 20 Jun 2021 23:27:37 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
Message-ID: <hiO3yJakh6pVoLeuzVc3IcVIRlGute5XLeurxXp7od4=.9eab4e95-0954-4859-b24e-cd018da1b169@github.com>

On Fri, 18 Jun 2021 19:23:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore run in EATests.java

Hi Patricio,

the part that's related to JDK-8227745 (40f847e2) looks good to me. Thanks for taking care of it!

Tests are pending...

Cheers, Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From dholmes at openjdk.java.net  Sun Jun 20 23:56:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 20 Jun 2021 23:56:37 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
Message-ID: <f-3BqjXN0yeIWcqn_bUwsD_aeqRKH1NLc2akscaCl2s=.bbce1eaf-f0c3-4fd8-ad4b-30e5a4015ae2@github.com>

On Fri, 18 Jun 2021 19:23:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore run in EATests.java

Updates look fine.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4522

From dholmes at openjdk.java.net  Mon Jun 21 00:33:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 00:33:25 GMT
Subject: [jdk17] RFR: 8269037: jsig/Testjsig.java doesn't have to be
 restricted to linux only
In-Reply-To: <qldZIqOSUVRlh1MUQEktviV8bxdqQjJQ4fXBbxxZ3Xc=.dc550af3-1e2c-4788-ac3d-284dea38a6f2@github.com>
References: <qldZIqOSUVRlh1MUQEktviV8bxdqQjJQ4fXBbxxZ3Xc=.dc550af3-1e2c-4788-ac3d-284dea38a6f2@github.com>
Message-ID: <czZLVnZh4aj-6R_xShbZ8_P5FBrGNlA597vjJxt_m8k=.f7e9f7bc-164c-4f88-a88b-5fa8d9178edd@github.com>

On Sun, 20 Jun 2021 11:08:21 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows?
> from JBS:
>> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is resticted to linux only, howere there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX.
> 
> testing:  `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64`
> 
> 
> Thanks,
> -- Igor

Hi Igor,

The changes seem fine but it seems risky to me to push this to 17 at this late stage as we don't know what quirks this test might expose on macOS.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk17/pull/105

From david.holmes at oracle.com  Mon Jun 21 01:53:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Jun 2021 11:53:36 +1000
Subject: A question about memory order on x86_64
In-Reply-To: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
Message-ID: <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>

Hi Xin,

I'm looking at your code again and apologies if we covered this 
previously but I'm not seeing how things are supposed to work exactly. 
Looking at the write() function :

void AsyncLogWriter::write() {
   AsyncLogBuffer logs;
   bool own_io = false;

   { // critical region
     AsyncLogLocker locker;

     _buffer.pop_all(&logs);
     // append meta-messages of dropped counters
     AsyncLogMapIterator dropped_counters_iter(logs);
     _stats.iterate(&dropped_counters_iter);
     own_io = _io_sem.trywait();
   }

   LinkedListIterator<AsyncLogMessage> it(logs.head());
   if (!own_io) {
     _io_sem.wait();
   }

   while (!it.is_empty()) {
     AsyncLogMessage* e = it.next();
     char* msg = e->message();

     if (msg != nullptr) {
       e->output()->write_blocking(e->decorations(), msg);

Supposed that a flush() operation has called write() and it has reached 
the point where it is about to release the io_sem at the end and gets 
descheduled. Other threads then perform logging operations that include 
a specific output N. The async log thread executes the code above, and 
stashes those log messages off in the local "logs" and then blocks on 
io_sem_wait. Let the original flush release the io_sem, and a second 
flush() commence due to the log configuration update that will delete 
output N. That flush also completes and releases the io_sem. The async 
log thread now acquires io_sem and attempts to write to the output that 
was just deleted.

David
-----

On 21/06/2021 6:50 am, Liu, Xin wrote:
> Hi, Hotspot experts,
> 
> I am debugging a PR which uses lock-free programming. David Holmes
> helped me submit this patch to the internal regression infra(thanks a
> lot). We got intermittent failures at tier4~7. There are two distinct
> crash sights, but they're similar. I guess the reason is asynclog thread
> observed different memory state from other threads.
> 
> https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283
> 
> I have spent a lot efforts on reproducing this problem. Eventually, I
> got a crash in docker and luckily coredump file and hs_err report were
> all saved.
> 
> In core dump file, I see this stacktraces in asynclog thread.
> 
> (gdb) bt
> ...
> #24 0x00007f76e1ab0e90 in flockfile () from /lib64/libc.so.6
> #25 0x00007f76e3d0c253 in FileLocker (file=0xbabababababababa,
> this=<synthetic pointer>) at
> /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
> #26 LogFileStreamOutput::write (this=0x55ea4d504bd0, decorations=...,
> msg=0x7f7624079b00 "ConcurrentLogsite 3 emits a log") at
> /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
> #27 0x00007f76e3d0b572 in LogFileOutput::write_blocking
> (this=0x55ea4d504bd0, decorations=..., msg=0x7f7624079b00
> "ConcurrentLogsite 3 emits a log") at
> /jdk/src/hotspot/share/logging/logFileOutput.cpp:308
> #28 0x00007f76e3d05bbd in write (this=0x55ea4d2e1af0) at
> /jdk/src/hotspot/share/logging/logAsyncWriter.hpp:106
> #29 AsyncLogWriter::run (this=0x55ea4d2e1af0) at
> /jdk/src/hotspot/share/logging/logAsyncWriter.cpp:163
> #30 0x00007f76e44696a0 in Thread::call_run (this=0x55ea4d2e1af0) at
> /jdk/src/hotspot/share/runtime/thread.cpp:394
> #31 0x00007f76e3fdf9b4 in thread_native_entry (thread=0x55ea4d2e1af0) at
> /jdk/src/hotspot/os/linux/os_linux.cpp:720
> #32 0x00007f76e162cea5 in start_thread () from /lib64/libpthread.so.0
> #33 0x00007f76e1b439fd in clone () from /lib64/libc.so.6
> 
> The corresponding code is here. _stream is 0xbabababababababa?
> 
> int LogFileStreamOutput::write(const LogDecorations& decorations, const
> char* msg) {
>    const bool use_decorations = !_decorators.is_empty();
> 
>    int written = 0;
>    FileLocker flocker(_stream);
>    if (use_decorations)
> 
> Here is the relevant disassembly code.
> ...prolog
> 0x7f76e3d0c223 <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+19>      mov    %rdi,%rbx
> 0x7f76e3d0c226 <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+22>      sub    $0x128,%rsp
> 0x7f76e3d0c22d <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+29>      mov    0x28(%rdi),%r15
> 0x7f76e3d0c231 <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+33>      mov    0x20(%rdi),%r12d
> 0x7f76e3d0c235 <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+37>      mov    %rdx,-0x148(%rbp)
> 0x7f76e3d0c23c <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+44>      mov    %r15,%rdi
> 0x7f76e3d0c23f <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+47>      mov    %fs:0x28,%rax
> 0x7f76e3d0c248 <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+56>      mov    %rax,-0x38(%rbp)
> 0x7f76e3d0c24c <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+60>      xor    %eax,%eax
> 0x7f76e3d0c24e <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+62>      callq  0x7f76e3feb090 <os::flockfile(_IO_FILE*)>
> 0x7f76e3d0c253 <LogFileStreamOutput::write(LogDecorations const&, char
> const*)+67>      test   %r12d,%r12d
> 
> 
> We can see that r15 = load 0x28(%rdi) and its value is bad. however, in
> memory, Its value is correct. this->_stream is 0x55ea4d0f8d00.
> 
> (gdb) p /x $r15
> $13 = 0xbabababababababa
> 
> (gdb) p /x $rbx
> $27 = 0x55ea4d504bd0
> 
> (gdb) x /1g $rbx + 0x28
> 0x55ea4d504bf8: 0x000055ea4d0f8d00
> 
> In main thread, we can see that output->_stream is well defined.
> 
> (gdb) p output
> $24 = (LogOutput *) 0x55ea4d504bd0
> 
> (gdb) p ((LogFileOutput*)output)->_stream
> $23 = (FILE *) 0x55ea4d0f8d00
> 
> 
> -------------------------------------------------------------------------
> 
> Can I say it's a memory ordering issue on x86_64? TBH, I can't explain
> how that happens.
> 
> Early moment in main thread, LogFileOutput::initialize() was called and
> _stream was initialized. After then, the program at least has gone through:
> 
> 1. Atomic::add (lock prefix instruction, which is implied store-load
> barrier?).
> 2. sem_wait/post (acquire-release semantics).
> 
> Therefore, I believe the current thread must see the written value of
> LogFileOutput::initialize(). ie. _stream should be (FILE *)
> 0x55ea4d0f8d00, not 0xbababa...
> 
> Last but not least question. To further understand this problem and
> verify patch, I think the key is to find a reproducible. Any thoughts on
> how to reproduce this kinda of problem?  So far, I only came across this
> crash once on my side. I used a docker image of Oracle Linux 7.9 (glibc
> 2.17) with cpuset 0~2.  Beside a core dump and a crash report, I can't
> reproduce it anymore. I think I must overlook some important factors
> here.  Really appreciate some head-ups.
> 
> I notice that Oracle is using 3-gen Zen architecture to run tests. Is it
> anything different from conventional x86_64? In AMD's manual[1], 7.4.2,
> Table-3, here is the description about lock-prefix instruction.
> 
> k  ? All loads and stores associated with the I/O and locked
> instructions complete to memory (no bufferedstores) before a load or
> store from a subsequent instruction is issued.
> 
> It seems to me that it doesn't imply "bidirectional full memory barrier"
> or storeload barrier. it just has acquire semantic. I read the story
> behind this change and Aleksey's article[2]. I'm just not sure the
> following code is equivalent to "mfence" on EPYC machines because AMD's
> manual is different from Intel's.
> 
> inline void OrderAccess::fence() {
>     // always use locked addl since mfence is sometimes expensive
> #ifdef AMD64
>    __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
> #else
>    __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
> #endif
>    compiler_barrier();
> }
> 
> 
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2]
> https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1
> 
> thanks,
> --lx
> 
> 
> 

From dholmes at openjdk.java.net  Mon Jun 21 02:20:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 02:20:27 GMT
Subject: [jdk17] RFR: 8268612: a few runtime/memory tests don't check exit
 code
In-Reply-To: <z2TsXyxDFqfWCwSbleuXG7T-W-YYbRPTzG12q_g6qM8=.b99795c8-f5ef-45d4-b084-fbabe03a62d8@github.com>
References: <z2TsXyxDFqfWCwSbleuXG7T-W-YYbRPTzG12q_g6qM8=.b99795c8-f5ef-45d4-b084-fbabe03a62d8@github.com>
Message-ID: <1vn91bUTjJ2MB828IKDNcLyq55mwWMdTwizYHxzbz_g=.bfbe980a-f07e-4718-9843-1d399b2fd969@github.com>

On Fri, 18 Jun 2021 10:55:08 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that adds checks of exit code to a few `runtime/memory` tests?
> from JBS:
>> `ReserveMemory.java`, `ReadFromNoaccessArea.java` and `TestLargePagesFlags.java` tests spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
> 
> in `ReadFromNoaccessArea.java`, the patch removes throwing of an exception in `DummyClassWithMainTryingToReadFromNoaccessArea` (child process), so we will get 0 as an exit code if/when we don't crash.
> 
> testing: `runtime/memory` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Sorry Igor I don't think 2 of these changes are needed/warranted.

David

test/hotspot/jtreg/runtime/memory/ReadFromNoaccessArea.java line 65:

> 63:       throw new SkippedException("There is no protected page in ReservedHeapSpace in these circumstance");
> 64:     }
> 65:     output.shouldNotHaveExitValue(0);

This is redundant. You will never have a zero exit value if you match the crash messages or else throw the exception. Seeing the crash message implies the return code is not zero so checking is a waste of time IMO not a more rigorous check. If the test did not crash then we won't match the expected output and we will still fail.

test/hotspot/jtreg/runtime/memory/ReserveMemory.java line 62:

> 60: 
> 61:     OutputAnalyzer output = new OutputAnalyzer(pb.start());
> 62:     output.shouldNotHaveExitValue(0);

Ditto - redundant.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/97

From dholmes at openjdk.java.net  Mon Jun 21 02:51:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 02:51:31 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v3]
In-Reply-To: <nsf8GfmmXppb1TK9vbBl5GDtWfOPImAH7QPx4zHtnoU=.616957e7-30d0-475f-9c4a-cccbdba874be@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <nsf8GfmmXppb1TK9vbBl5GDtWfOPImAH7QPx4zHtnoU=.616957e7-30d0-475f-9c4a-cccbdba874be@github.com>
Message-ID: <3E_o4Db8MAJloBCQoxl6zAyMc-ZuNlHXkBtSXQw9Scg=.5912da32-eb7e-4fcb-a66c-a8dbbdb3b6a4@github.com>

On Fri, 18 Jun 2021 13:57:05 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
>> 
>> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
>> 
>> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
>> 
>> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add check_compatibility argument

src/hotspot/share/classfile/classFileParser.hpp line 464:

> 462:   int  verify_legal_method_signature(const Symbol* methodname,
> 463:                                      const Symbol* signature,
> 464:                                      bool check_compatibility,

Can't help but think this method is trying to perform two jobs when it should only be doing one. What we previously considered "legal" is not actually a check of legality per-se as it is context specific. Perhaps this should really be split into two sets of checks?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From dholmes at openjdk.java.net  Mon Jun 21 04:22:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 04:22:30 GMT
Subject: [jdk17] RFR: 8268612: a few runtime/memory tests don't check exit
 code
In-Reply-To: <z2TsXyxDFqfWCwSbleuXG7T-W-YYbRPTzG12q_g6qM8=.b99795c8-f5ef-45d4-b084-fbabe03a62d8@github.com>
References: <z2TsXyxDFqfWCwSbleuXG7T-W-YYbRPTzG12q_g6qM8=.b99795c8-f5ef-45d4-b084-fbabe03a62d8@github.com>
Message-ID: <kBYyaMuVpSJg8Hl-Qf5ptSxGoMQtID0CGML7iqi8T14=.ff88a4d7-ace0-42b9-a4c4-fcbc17e3db3d@github.com>

On Fri, 18 Jun 2021 10:55:08 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that adds checks of exit code to a few `runtime/memory` tests?
> from JBS:
>> `ReserveMemory.java`, `ReadFromNoaccessArea.java` and `TestLargePagesFlags.java` tests spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
> 
> in `ReadFromNoaccessArea.java`, the patch removes throwing of an exception in `DummyClassWithMainTryingToReadFromNoaccessArea` (child process), so we will get 0 as an exit code if/when we don't crash.
> 
> testing: `runtime/memory` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Hi Igor,

Apologies for my previous review it was a bit brash.

A small change suggested in ReserveMemoryTest - you should also remove the throwing of the exception on a successful read as you did for  ReadFromNoAccess.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/97

From dholmes at openjdk.java.net  Mon Jun 21 04:22:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 04:22:30 GMT
Subject: [jdk17] RFR: 8268612: a few runtime/memory tests don't check exit
 code
In-Reply-To: <1vn91bUTjJ2MB828IKDNcLyq55mwWMdTwizYHxzbz_g=.bfbe980a-f07e-4718-9843-1d399b2fd969@github.com>
References: <z2TsXyxDFqfWCwSbleuXG7T-W-YYbRPTzG12q_g6qM8=.b99795c8-f5ef-45d4-b084-fbabe03a62d8@github.com>
 <1vn91bUTjJ2MB828IKDNcLyq55mwWMdTwizYHxzbz_g=.bfbe980a-f07e-4718-9843-1d399b2fd969@github.com>
Message-ID: <oQFKJCdERKQWOyHjMLblujo0WsdGkRd1DsvVaumScBA=.d7b1f053-9427-4539-8668-d8932755c6f7@github.com>

On Mon, 21 Jun 2021 02:13:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch that adds checks of exit code to a few `runtime/memory` tests?
>> from JBS:
>>> `ReserveMemory.java`, `ReadFromNoaccessArea.java` and `TestLargePagesFlags.java` tests spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors
>> 
>> in `ReadFromNoaccessArea.java`, the patch removes throwing of an exception in `DummyClassWithMainTryingToReadFromNoaccessArea` (child process), so we will get 0 as an exit code if/when we don't crash.
>> 
>> testing: `runtime/memory` tests on `{linux,windows,macosx}-x64`
>> 
>> Thanks,
>> -- Igor
>
> test/hotspot/jtreg/runtime/memory/ReadFromNoaccessArea.java line 65:
> 
>> 63:       throw new SkippedException("There is no protected page in ReservedHeapSpace in these circumstance");
>> 64:     }
>> 65:     output.shouldNotHaveExitValue(0);
> 
> This is redundant. You will never have a zero exit value if you match the crash messages or else throw the exception. Seeing the crash message implies the return code is not zero so checking is a waste of time IMO not a more rigorous check. If the test did not crash then we won't match the expected output and we will still fail.

Sorry, please ignore my previous comment. If we inadvertently caused the call to exit with a zero return in case of a crash, this change would detect it.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/97

From dholmes at openjdk.java.net  Mon Jun 21 04:28:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 04:28:27 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <kctvOq6V6i3nX77Vr59S30O6g9DnUB9eqZ_jCTYcRfc=.0893c1a5-d97e-4254-970e-25206bf1c1df@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

Hi Coleen,

What about an attaching thread that hits a handshake when trying to allocate the java.lang.Thread object?

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From david.holmes at oracle.com  Mon Jun 21 06:21:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Jun 2021 16:21:43 +1000
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <550e9971-7b9d-f480-b5d5-792ff91f8fbe@oracle.com>

Hi Thomas,

On 17/06/2021 4:41 pm, Thomas Stuefe wrote:
> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.

Is it perhaps worthwhile trying to generalize this to a jcmd to request 
an attempt to release system resources and then each platform can do 
whatever may be available to assist in that - including doing nothing, 
or in this case trimming the glibc heap ?

Thanks,
David
-----

> If this finds agreement, I will file a CSR.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                     ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                     ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)
> 
> -------------
> 
> Commit messages:
>   - start
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4510/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8268893
>    Stats: 237 lines in 6 files changed: 212 ins; 7 del; 18 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4510.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510
> 
> PR: https://git.openjdk.java.net/jdk/pull/4510
> 

From stuefe at openjdk.java.net  Mon Jun 21 07:10:26 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Jun 2021 07:10:26 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <3w036PFQz_qIY9WLpwc-vfeAx3kTclEKVpaRboas75M=.bab4028c-d836-4561-9877-e4acdad5cdda@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

Hi David,

thanks for looking into this!

> Is it perhaps worthwhile trying to generalize this to a jcmd to request
> an attempt to release system resources and then each platform can do
> whatever may be available to assist in that - including doing nothing,
> or in this case trimming the glibc heap ?
> 

I thought about this too. It would certainly make the jcmd look nicer. 

But I think that this would be one of the cases where the supporter needs to know the details of what the command does under the hood, so by hiding the complexity behind the platform nothing is gained; you need to know what happens to gauge the influence it has on the system (eg performance loss by dropping caches) and to analyze the precise after-effects. I

I am undecided on this. I will ask around offline.

..Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From simonis at openjdk.java.net  Mon Jun 21 09:18:31 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 21 Jun 2021 09:18:31 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

I like this little new diagnostic command which I think can be quite useful in specific situations.

However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.

I'd therefore propose to rename this command to `glibc_trim_heap` to make it evident from the command name already that it is Glibc-specific.

Besides that, just cosmetic changes and suggestions.

src/hotspot/os/linux/os_linux.cpp line 2142:

> 2140: bool os::Linux::query_process_memory_info(os::Linux::meminfo_t* info) {
> 2141:   FILE* f = ::fopen("/proc/self/status", "r");
> 2142:   const int num_values = 8;

Refactoring of `os::Linux::print_process_memory_info` looks good. But now that you've already created `os::Linux::meminfo_t` anyway I'd suggest to make `num_values == sizeof(os::Linux::meminfo_t)/sizeof(ssize_t)`.

src/hotspot/os/linux/trimCHeapDCmd.cpp line 43:

> 41:   os::Linux::meminfo_t info2;
> 42:   bool have_info1 = os::Linux::query_process_memory_info(&info1);
> 43: 

os::Linux::meminfo_t info1;
  os::Linux::meminfo_t info2;
  // Query memory before...
  bool have_info1 = os::Linux::query_process_memory_info(&info1);

Looks better to me :)

src/hotspot/os/linux/trimCHeapDCmd.cpp line 64:

> 62:       ss_report.print_cr("Swap before: " SSIZE_FORMAT "k, after: " SSIZE_FORMAT "k, (" SSIZE_FORMAT "k)",
> 63:                          info1.vmswap, info2.vmswap, (info2.vmswap - info1.vmswap));
> 64:     }

In the unusual case that `(have_info1 && have_info2)==true` but there was still nothing printed (i.e. `info1.vmsize == -1 || info2.vmsize == -1` etc.), you should still print out `"No details available."`.

src/hotspot/share/services/diagnosticCommand.cpp line 99:

> 97:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapInfoDCmd>(full_export, true, false));
> 98:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<FinalizerInfoDCmd>(full_export, true, false));
> 99:   LINUX_ONLY(DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));)

Not sure if the commands are really sorted and if order is important here. Otherwise you could add the new command a few lines later where there already exists an `#ifdef LINUX` section:


#ifdef LINUX
  DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<PerfMapDCmd>(full_export, true, false));
  DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));
#endif // LINUX

test/hotspot/jtreg/serviceability/dcmd/vm/TrimLibcHeapTest.java line 46:

> 44:         output.reportDiagnosticSummary();
> 45:         output.shouldMatch("(Done|Not available)");
> 46:     }

Maybe also add something like:

if (output.firstMatch("Done") != null) {
  output.shouldMatch("(Virtual size before|RSS before|Swap before|No details available)");
}

-------------

Changes requested by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Mon Jun 21 09:58:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Jun 2021 09:58:32 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
Message-ID: <fz_W7O0zXVWJkJMyhR0sUP8WO8wAdybXtbazf5fMUF8=.26e70614-9961-4679-a02c-0e68b2f39617@github.com>

On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> I like this little new diagnostic command which I think can be quite useful in specific situations.
> 

Thanks a lot Volker!

> However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.

Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one. 

> 
> I'd therefore propose to rename this command to `glibc_trim_heap` to make it evident from the command name already that it is Glibc-specific.
> 
> Besides that, just cosmetic changes and suggestions.

All of which make sense, I'll work them in.

Thanks!

..Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From david.holmes at oracle.com  Mon Jun 21 12:11:41 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Jun 2021 22:11:41 +1000
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <fz_W7O0zXVWJkJMyhR0sUP8WO8wAdybXtbazf5fMUF8=.26e70614-9961-4679-a02c-0e68b2f39617@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
 <fz_W7O0zXVWJkJMyhR0sUP8WO8wAdybXtbazf5fMUF8=.26e70614-9961-4679-a02c-0e68b2f39617@github.com>
Message-ID: <e3c82bde-9daf-8440-59f0-6d5c96cb4fcf@oracle.com>

On 21/06/2021 7:58 pm, Thomas Stuefe wrote:
> On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> 
>> I like this little new diagnostic command which I think can be quite useful in specific situations.
>>
> 
> Thanks a lot Volker!
> 
>> However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.
> 
> Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one.

I don't totally oppose the specialised variant, but it certainly isn't 
my ideal solution. Not sure if we already have platform specific dcmds? 
This will need a CSR request anyway.

Cheers,
David

>>
>> I'd therefore propose to rename this command to `glibc_trim_heap` to make it evident from the command name already that it is Glibc-specific.
>>
>> Besides that, just cosmetic changes and suggestions.
> 
> All of which make sense, I'll work them in.
> 
> Thanks!
> 
> ..Thomas
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4510
> 

From stuefe at openjdk.java.net  Mon Jun 21 12:29:30 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Jun 2021 12:29:30 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <5VXQj2nuY6vuYZ7SE1DT2_-ZbcFYI7XKr_I_LcwyFnc=.34ce0ea1-53bc-413b-beb4-1344fd22a0c1@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 21/06/2021 7:58 pm, Thomas Stuefe wrote:
> 
> > On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> > > I like this little new diagnostic command which I think can be quite useful in specific situations.
> > 
> > 
> > Thanks a lot Volker!
> > > However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.
> > 
> > 
> > Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one.
> 
> I don't totally oppose the specialised variant, but it certainly isn't
> my ideal solution. Not sure if we already have platform specific dcmds?
> This will need a CSR request anyway.
> 
> Cheers,
> David

I'll prepare the CSR and bring it to review.

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From rrich at openjdk.java.net  Mon Jun 21 13:04:34 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 21 Jun 2021 13:04:34 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
Message-ID: <vLH09NOV0vp8n0F_EHxLnzcayPSC5e_EvHIBMB4qH6c=.bbf33968-625e-46ca-bd47-cb8dcc0e75df@github.com>

On Fri, 18 Jun 2021 19:23:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore run in EATests.java

No issues from my own testing. Broader test coverage on all platforms is expected tomorrow.

Best regards,
Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Mon Jun 21 14:01:33 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 21 Jun 2021 14:01:33 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <vHsCkHlzcON-tD9tV2jyGdvD11k9vcttFcjOD2QD5eA=.d327144a-2165-4679-b097-4946ead99149@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
 <vHsCkHlzcON-tD9tV2jyGdvD11k9vcttFcjOD2QD5eA=.d327144a-2165-4679-b097-4946ead99149@github.com>
Message-ID: <eRYudTQH3JQ9wdB1P8LpjCb-xtVDrNwokrBjtZEg570=.0e125cfe-8dcd-4327-b70f-cbdc0e54e9b7@github.com>

On Sun, 20 Jun 2021 14:12:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

> AArch64 changes look good.
Thanks for checking AArch64 changes @theRealAph!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Mon Jun 21 14:01:33 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 21 Jun 2021 14:01:33 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <vLH09NOV0vp8n0F_EHxLnzcayPSC5e_EvHIBMB4qH6c=.bbf33968-625e-46ca-bd47-cb8dcc0e75df@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
 <vLH09NOV0vp8n0F_EHxLnzcayPSC5e_EvHIBMB4qH6c=.bbf33968-625e-46ca-bd47-cb8dcc0e75df@github.com>
Message-ID: <WvSUdGuMxCXRGZlRejUQoqo9VuURAZBqI4yVAB9sYw4=.5da37a9f-feff-4e8d-bdd4-54b917e16801@github.com>

On Mon, 21 Jun 2021 13:01:39 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> No issues from my own testing. Broader test coverage on all platforms is expected tomorrow.
Great, I'll wait for that. Thanks for all the testing Richard!

Patricio

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Mon Jun 21 14:49:20 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 21 Jun 2021 14:49:20 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v5]
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Un-ProblemList serviceability tests (8268574 and 8268644)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4522/files
  - new: https://git.openjdk.java.net/jdk/pull/4522/files/215e46b8..c6015171

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=03-04

  Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From coleenp at openjdk.java.net  Mon Jun 21 15:16:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 21 Jun 2021 15:16:41 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be 'jint'
Message-ID: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>

I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

-------------

Commit messages:
 - 8256306: ObjectMonitor::_contentions field should not be 'jint'

Changes: https://git.openjdk.java.net/jdk/pull/3980/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3980&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256306
  Stats: 27 lines in 5 files changed: 1 ins; 0 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3980.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3980/head:pull/3980

PR: https://git.openjdk.java.net/jdk/pull/3980

From simonis at openjdk.java.net  Mon Jun 21 15:27:32 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 21 Jun 2021 15:27:32 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <5VXQj2nuY6vuYZ7SE1DT2_-ZbcFYI7XKr_I_LcwyFnc=.34ce0ea1-53bc-413b-beb4-1344fd22a0c1@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <5VXQj2nuY6vuYZ7SE1DT2_-ZbcFYI7XKr_I_LcwyFnc=.34ce0ea1-53bc-413b-beb4-1344fd22a0c1@github.com>
Message-ID: <6EK1VCEXEziiI-GfZocHjcO1uAUDnEsLF11rAky6o74=.dfbe3e0e-f544-4073-b81b-df908c0b121d@github.com>

On Mon, 21 Jun 2021 12:26:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 21/06/2021 7:58 pm, Thomas Stuefe wrote:
> 
> > On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> > > I like this little new diagnostic command which I think can be quite useful in specific situations.
> > 
> > 
> > Thanks a lot Volker!
> > > However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.
> > 
> > 
> > Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one.
> 
> I don't totally oppose the specialised variant, but it certainly isn't
> my ideal solution. Not sure if we already have platform specific dcmds?

Yes, we have. E.g.:

#ifdef LINUX
class PerfMapDCmd : public DCmd {
public:
  PerfMapDCmd(outputStream* output, bool heap) : DCmd(output, heap) {}
  static const char* name() {
    return "Compiler.perfmap";
  }
  static const char* description() {
    return "Write map file for Linux perf tool.";
  }
...


> This will need a CSR request anyway.
> 
> Cheers,
> David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From coleen.phillimore at oracle.com  Mon Jun 21 15:41:34 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 21 Jun 2021 11:41:34 -0400
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <kctvOq6V6i3nX77Vr59S30O6g9DnUB9eqZ_jCTYcRfc=.0893c1a5-d97e-4254-970e-25206bf1c1df@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
 <kctvOq6V6i3nX77Vr59S30O6g9DnUB9eqZ_jCTYcRfc=.0893c1a5-d97e-4254-970e-25206bf1c1df@github.com>
Message-ID: <e78d48fa-36f8-e24b-2009-8c1798b510ed@oracle.com>



On 6/21/21 12:28 AM, David Holmes wrote:
> On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
>> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
>>
>> Tested with tier1-6.
> Hi Coleen,
>
> What about an attaching thread that hits a handshake when trying to allocate the java.lang.Thread object?

The attaching thread can't be handshake because it hasn't been added to 
the Threads list until threadObj is initialized.? As far as I can tell, 
you can't handshake a thread that's not on the list.

Coleen

>
> David
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4512


From hseigel at openjdk.java.net  Mon Jun 21 17:11:05 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 21 Jun 2021 17:11:05 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v4]
In-Reply-To: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
Message-ID: <dLXZ4E9xptK3pKFpfjG0bq8ohETgRpY33K4GHtgz-Yc=.c7681e38-95ba-4dc5-a68e-2960b5ffc87c@github.com>

> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
> 
> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
> 
> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
> 
> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  split verify_legal_method_signature() into two methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4497/files
  - new: https://git.openjdk.java.net/jdk/pull/4497/files/0d063d6b..b42efc40

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=02-03

  Stats: 60 lines in 2 files changed: 32 ins; 20 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4497/head:pull/4497

PR: https://git.openjdk.java.net/jdk/pull/4497

From hseigel at openjdk.java.net  Mon Jun 21 17:16:33 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 21 Jun 2021 17:16:33 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v3]
In-Reply-To: <3E_o4Db8MAJloBCQoxl6zAyMc-ZuNlHXkBtSXQw9Scg=.5912da32-eb7e-4fcb-a66c-a8dbbdb3b6a4@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <nsf8GfmmXppb1TK9vbBl5GDtWfOPImAH7QPx4zHtnoU=.616957e7-30d0-475f-9c4a-cccbdba874be@github.com>
 <3E_o4Db8MAJloBCQoxl6zAyMc-ZuNlHXkBtSXQw9Scg=.5912da32-eb7e-4fcb-a66c-a8dbbdb3b6a4@github.com>
Message-ID: <EvPHQ23QZR9sMis3pgUMZ7gSJ0iou7syi4E4T3FfJro=.b6703bfe-81a1-499f-803c-8a6596b6d3ad@github.com>

On Mon, 21 Jun 2021 02:48:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add check_compatibility argument
>
> src/hotspot/share/classfile/classFileParser.hpp line 464:
> 
>> 462:   int  verify_legal_method_signature(const Symbol* methodname,
>> 463:                                      const Symbol* signature,
>> 464:                                      bool check_compatibility,
> 
> Can't help but think this method is trying to perform two jobs when it should only be doing one. What we previously considered "legal" is not actually a check of legality per-se as it is context specific. Perhaps this should really be split into two sets of checks?

Hi David, please review the latest commit that breaks verify_legal_method_signatures() into two functions, one that checks that the signature is legal, and the other, verify_legal_name_with_signature(), that checks that the method name and signature are compatible with each other.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From navy.xliu at gmail.com  Mon Jun 21 20:49:13 2021
From: navy.xliu at gmail.com (Liu Xin)
Date: Mon, 21 Jun 2021 13:49:13 -0700
Subject: A question about memory order on x86_64
In-Reply-To: <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
Message-ID: <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>

hi, David,

Thanks. This is my blindspot. Let me go through your description. There are
3 threads. M is the main thread which is doing logConfiguration changes.
A is the async log thread, which is flushing. L is a user thread which is
emitting logs.

M: flush1/sem_wait ---- ---- ---- ---- ---- ---- ---- flush1/sem_post ----
flush2/sem_wait ---- flush2/sem.post ---- delete_output() ----
L: ---- ---- enqueue(log1) ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
A: ---- ---- ---- ---- ---- dequeue(log1) ---- run/sem_wait ---- ---- ----
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
write_blocking(log1)

This is the timeline you described, isn't it? A key missing information is
that sem_wait() (POSIX semaphore) doesn't respect FIFO order.
I thought Thread-A has invoked run/sem_wait() first. If flush1/sem_post()
is called, kernel must wake up thread A immediately. It may NOT  the case,
right?
It's possible that thread-A is descheduled and thread-M can keep going.
Under the hook, I see that glibc implements sem_wait using syscall futex.

In my test, I stupidly put two set_log_config() in a loop. Therefore, M
invokes two flush() in a row!
https://github.com/openjdk/jdk/pull/4408/files#diff-25062d200033077d44dacb5aae6b8141316b4bc10149c061cf047fe7db250d98R306

Let me try to simulate this and see if I have a fix.

Thanks,
-lx




On Sun, Jun 20, 2021 at 6:54 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Xin,
>
> I'm looking at your code again and apologies if we covered this
> previously but I'm not seeing how things are supposed to work exactly.
> Looking at the write() function :
>
> void AsyncLogWriter::write() {
>    AsyncLogBuffer logs;
>    bool own_io = false;
>
>    { // critical region
>      AsyncLogLocker locker;
>
>      _buffer.pop_all(&logs);
>      // append meta-messages of dropped counters
>      AsyncLogMapIterator dropped_counters_iter(logs);
>      _stats.iterate(&dropped_counters_iter);
>      own_io = _io_sem.trywait();
>    }
>
>    LinkedListIterator<AsyncLogMessage> it(logs.head());
>    if (!own_io) {
>      _io_sem.wait();
>    }
>
>    while (!it.is_empty()) {
>      AsyncLogMessage* e = it.next();
>      char* msg = e->message();
>
>      if (msg != nullptr) {
>        e->output()->write_blocking(e->decorations(), msg);
>
> Supposed that a flush() operation has called write() and it has reached
> the point where it is about to release the io_sem at the end and gets
> descheduled. Other threads then perform logging operations that include
> a specific output N. The async log thread executes the code above, and
> stashes those log messages off in the local "logs" and then blocks on
> io_sem_wait. Let the original flush release the io_sem, and a second
> flush() commence due to the log configuration update that will delete
> output N. That flush also completes and releases the io_sem. The async
> log thread now acquires io_sem and attempts to write to the output that
> was just deleted.
>
> David
> -----
>
> On 21/06/2021 6:50 am, Liu, Xin wrote:
> > Hi, Hotspot experts,
> >
> > I am debugging a PR which uses lock-free programming. David Holmes
> > helped me submit this patch to the internal regression infra(thanks a
> > lot). We got intermittent failures at tier4~7. There are two distinct
> > crash sights, but they're similar. I guess the reason is asynclog thread
> > observed different memory state from other threads.
> >
> > https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283
> >
> > I have spent a lot efforts on reproducing this problem. Eventually, I
> > got a crash in docker and luckily coredump file and hs_err report were
> > all saved.
> >
> > In core dump file, I see this stacktraces in asynclog thread.
> >
> > (gdb) bt
> > ...
> > #24 0x00007f76e1ab0e90 in flockfile () from /lib64/libc.so.6
> > #25 0x00007f76e3d0c253 in FileLocker (file=0xbabababababababa,
> > this=<synthetic pointer>) at
> > /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
> > #26 LogFileStreamOutput::write (this=0x55ea4d504bd0, decorations=...,
> > msg=0x7f7624079b00 "ConcurrentLogsite 3 emits a log") at
> > /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
> > #27 0x00007f76e3d0b572 in LogFileOutput::write_blocking
> > (this=0x55ea4d504bd0, decorations=..., msg=0x7f7624079b00
> > "ConcurrentLogsite 3 emits a log") at
> > /jdk/src/hotspot/share/logging/logFileOutput.cpp:308
> > #28 0x00007f76e3d05bbd in write (this=0x55ea4d2e1af0) at
> > /jdk/src/hotspot/share/logging/logAsyncWriter.hpp:106
> > #29 AsyncLogWriter::run (this=0x55ea4d2e1af0) at
> > /jdk/src/hotspot/share/logging/logAsyncWriter.cpp:163
> > #30 0x00007f76e44696a0 in Thread::call_run (this=0x55ea4d2e1af0) at
> > /jdk/src/hotspot/share/runtime/thread.cpp:394
> > #31 0x00007f76e3fdf9b4 in thread_native_entry (thread=0x55ea4d2e1af0) at
> > /jdk/src/hotspot/os/linux/os_linux.cpp:720
> > #32 0x00007f76e162cea5 in start_thread () from /lib64/libpthread.so.0
> > #33 0x00007f76e1b439fd in clone () from /lib64/libc.so.6
> >
> > The corresponding code is here. _stream is 0xbabababababababa?
> >
> > int LogFileStreamOutput::write(const LogDecorations& decorations, const
> > char* msg) {
> >    const bool use_decorations = !_decorators.is_empty();
> >
> >    int written = 0;
> >    FileLocker flocker(_stream);
> >    if (use_decorations)
> >
> > Here is the relevant disassembly code.
> > ...prolog
> > 0x7f76e3d0c223 <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+19>      mov    %rdi,%rbx
> > 0x7f76e3d0c226 <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+22>      sub    $0x128,%rsp
> > 0x7f76e3d0c22d <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+29>      mov    0x28(%rdi),%r15
> > 0x7f76e3d0c231 <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+33>      mov    0x20(%rdi),%r12d
> > 0x7f76e3d0c235 <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+37>      mov    %rdx,-0x148(%rbp)
> > 0x7f76e3d0c23c <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+44>      mov    %r15,%rdi
> > 0x7f76e3d0c23f <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+47>      mov    %fs:0x28,%rax
> > 0x7f76e3d0c248 <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+56>      mov    %rax,-0x38(%rbp)
> > 0x7f76e3d0c24c <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+60>      xor    %eax,%eax
> > 0x7f76e3d0c24e <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+62>      callq  0x7f76e3feb090 <os::flockfile(_IO_FILE*)>
> > 0x7f76e3d0c253 <LogFileStreamOutput::write(LogDecorations const&, char
> > const*)+67>      test   %r12d,%r12d
> >
> >
> > We can see that r15 = load 0x28(%rdi) and its value is bad. however, in
> > memory, Its value is correct. this->_stream is 0x55ea4d0f8d00.
> >
> > (gdb) p /x $r15
> > $13 = 0xbabababababababa
> >
> > (gdb) p /x $rbx
> > $27 = 0x55ea4d504bd0
> >
> > (gdb) x /1g $rbx + 0x28
> > 0x55ea4d504bf8: 0x000055ea4d0f8d00
> >
> > In main thread, we can see that output->_stream is well defined.
> >
> > (gdb) p output
> > $24 = (LogOutput *) 0x55ea4d504bd0
> >
> > (gdb) p ((LogFileOutput*)output)->_stream
> > $23 = (FILE *) 0x55ea4d0f8d00
> >
> >
> > -------------------------------------------------------------------------
> >
> > Can I say it's a memory ordering issue on x86_64? TBH, I can't explain
> > how that happens.
> >
> > Early moment in main thread, LogFileOutput::initialize() was called and
> > _stream was initialized. After then, the program at least has gone
> through:
> >
> > 1. Atomic::add (lock prefix instruction, which is implied store-load
> > barrier?).
> > 2. sem_wait/post (acquire-release semantics).
> >
> > Therefore, I believe the current thread must see the written value of
> > LogFileOutput::initialize(). ie. _stream should be (FILE *)
> > 0x55ea4d0f8d00, not 0xbababa...
> >
> > Last but not least question. To further understand this problem and
> > verify patch, I think the key is to find a reproducible. Any thoughts on
> > how to reproduce this kinda of problem?  So far, I only came across this
> > crash once on my side. I used a docker image of Oracle Linux 7.9 (glibc
> > 2.17) with cpuset 0~2.  Beside a core dump and a crash report, I can't
> > reproduce it anymore. I think I must overlook some important factors
> > here.  Really appreciate some head-ups.
> >
> > I notice that Oracle is using 3-gen Zen architecture to run tests. Is it
> > anything different from conventional x86_64? In AMD's manual[1], 7.4.2,
> > Table-3, here is the description about lock-prefix instruction.
> >
> > k  ? All loads and stores associated with the I/O and locked
> > instructions complete to memory (no bufferedstores) before a load or
> > store from a subsequent instruction is issued.
> >
> > It seems to me that it doesn't imply "bidirectional full memory barrier"
> > or storeload barrier. it just has acquire semantic. I read the story
> > behind this change and Aleksey's article[2]. I'm just not sure the
> > following code is equivalent to "mfence" on EPYC machines because AMD's
> > manual is different from Intel's.
> >
> > inline void OrderAccess::fence() {
> >     // always use locked addl since mfence is sometimes expensive
> > #ifdef AMD64
> >    __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
> > #else
> >    __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
> > #endif
> >    compiler_barrier();
> > }
> >
> >
> > [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> > [2]
> >
> https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1
> >
> > thanks,
> > --lx
> >
> >
> >
>

From david.holmes at oracle.com  Mon Jun 21 22:02:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 08:02:58 +1000
Subject: A question about memory order on x86_64
In-Reply-To: <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
Message-ID: <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>

On 22/06/2021 6:49 am, Liu Xin wrote:
> hi, David,
> 
> Thanks. This is my blindspot. Let me go through your description. There 
> are 3 threads. M is the main thread which is doing logConfiguration changes.
> A is the async log thread, which is flushing. L is a user thread which 
> is emitting logs.
> 
> M: flush1/sem_wait ---- ---- ---- ---- ---- ---- ---- flush1/sem_post 
> ---- flush2/sem_wait ---- flush2/sem.post <http://sem.post> ---- 
> delete_output() ----
> L: ---- ---- enqueue(log1) ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
> A: ---- ---- ---- ---- ---- dequeue(log1) ---- run/sem_wait ---- ---- 
> ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 
> write_blocking(log1)
> 
> This is the timeline you described, isn't it?

Probably close enough.

> A key missing information 
> is that sem_wait() (POSIX semaphore) doesn't respect FIFO order.
> I thought Thread-A has invoked run/sem_wait() first. If 
> flush1/sem_post() is called, kernel must wake up thread A immediately. 
> It may NOT? the case, right?

Right there are no guarantees that when M calls signal/post to wakeup A, 
that A will actually get to run and consume the token and so return from 
sem_wait. If the implementation is based on futex then it is likely 
similar to mutex operation and the newly woken thread will contend with 
all other threads to try and claim the semaphore. In such cases if M 
calls sem_wait very shortly after sem_post then it will likely reclaim 
the semaphore.

> It's possible that thread-A is descheduled and thread-M can keep going. 
> Under the hook, I see that glibc implements sem_wait using syscall futex.
> 
> In my test, I stupidly put two set_log_config() in a loop. Therefore, M 
> invokes two flush() in a row!
> https://github.com/openjdk/jdk/pull/4408/files#diff-25062d200033077d44dacb5aae6b8141316b4bc10149c061cf047fe7db250d98R306 
> <https://github.com/openjdk/jdk/pull/4408/files#diff-25062d200033077d44dacb5aae6b8141316b4bc10149c061cf047fe7db250d98R306>
> 
> Let me try to simulate this and see if I have a fix.

I'm beginning to think that the only safe thing to do here is to 
lock-out configuration changes while any write is in progress.

David
-----

> Thanks,
> -lx
> 
> 
> 
> 
> On Sun, Jun 20, 2021 at 6:54 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Xin,
> 
>     I'm looking at your code again and apologies if we covered this
>     previously but I'm not seeing how things are supposed to work exactly.
>     Looking at the write() function :
> 
>     void AsyncLogWriter::write() {
>      ? ?AsyncLogBuffer logs;
>      ? ?bool own_io = false;
> 
>      ? ?{ // critical region
>      ? ? ?AsyncLogLocker locker;
> 
>      ? ? ?_buffer.pop_all(&logs);
>      ? ? ?// append meta-messages of dropped counters
>      ? ? ?AsyncLogMapIterator dropped_counters_iter(logs);
>      ? ? ?_stats.iterate(&dropped_counters_iter);
>      ? ? ?own_io = _io_sem.trywait();
>      ? ?}
> 
>      ? ?LinkedListIterator<AsyncLogMessage> it(logs.head());
>      ? ?if (!own_io) {
>      ? ? ?_io_sem.wait();
>      ? ?}
> 
>      ? ?while (!it.is_empty()) {
>      ? ? ?AsyncLogMessage* e = it.next();
>      ? ? ?char* msg = e->message();
> 
>      ? ? ?if (msg != nullptr) {
>      ? ? ? ?e->output()->write_blocking(e->decorations(), msg);
> 
>     Supposed that a flush() operation has called write() and it has reached
>     the point where it is about to release the io_sem at the end and gets
>     descheduled. Other threads then perform logging operations that include
>     a specific output N. The async log thread executes the code above, and
>     stashes those log messages off in the local "logs" and then blocks on
>     io_sem_wait. Let the original flush release the io_sem, and a second
>     flush() commence due to the log configuration update that will delete
>     output N. That flush also completes and releases the io_sem. The async
>     log thread now acquires io_sem and attempts to write to the output that
>     was just deleted.
> 
>     David
>     -----
> 
>     On 21/06/2021 6:50 am, Liu, Xin wrote:
>      > Hi, Hotspot experts,
>      >
>      > I am debugging a PR which uses lock-free programming. David Holmes
>      > helped me submit this patch to the internal regression infra(thanks a
>      > lot). We got intermittent failures at tier4~7. There are two distinct
>      > crash sights, but they're similar. I guess the reason is asynclog
>     thread
>      > observed different memory state from other threads.
>      >
>      > https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283
>     <https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283>
>      >
>      > I have spent a lot efforts on reproducing this problem. Eventually, I
>      > got a crash in docker and luckily coredump file and hs_err report
>     were
>      > all saved.
>      >
>      > In core dump file, I see this stacktraces in asynclog thread.
>      >
>      > (gdb) bt
>      > ...
>      > #24 0x00007f76e1ab0e90 in flockfile () from /lib64/libc.so.6
>      > #25 0x00007f76e3d0c253 in FileLocker (file=0xbabababababababa,
>      > this=<synthetic pointer>) at
>      > /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
>      > #26 LogFileStreamOutput::write (this=0x55ea4d504bd0, decorations=...,
>      > msg=0x7f7624079b00 "ConcurrentLogsite 3 emits a log") at
>      > /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
>      > #27 0x00007f76e3d0b572 in LogFileOutput::write_blocking
>      > (this=0x55ea4d504bd0, decorations=..., msg=0x7f7624079b00
>      > "ConcurrentLogsite 3 emits a log") at
>      > /jdk/src/hotspot/share/logging/logFileOutput.cpp:308
>      > #28 0x00007f76e3d05bbd in write (this=0x55ea4d2e1af0) at
>      > /jdk/src/hotspot/share/logging/logAsyncWriter.hpp:106
>      > #29 AsyncLogWriter::run (this=0x55ea4d2e1af0) at
>      > /jdk/src/hotspot/share/logging/logAsyncWriter.cpp:163
>      > #30 0x00007f76e44696a0 in Thread::call_run (this=0x55ea4d2e1af0) at
>      > /jdk/src/hotspot/share/runtime/thread.cpp:394
>      > #31 0x00007f76e3fdf9b4 in thread_native_entry
>     (thread=0x55ea4d2e1af0) at
>      > /jdk/src/hotspot/os/linux/os_linux.cpp:720
>      > #32 0x00007f76e162cea5 in start_thread () from /lib64/libpthread.so.0
>      > #33 0x00007f76e1b439fd in clone () from /lib64/libc.so.6
>      >
>      > The corresponding code is here. _stream is 0xbabababababababa?
>      >
>      > int LogFileStreamOutput::write(const LogDecorations& decorations,
>     const
>      > char* msg) {
>      >? ? const bool use_decorations = !_decorators.is_empty();
>      >
>      >? ? int written = 0;
>      >? ? FileLocker flocker(_stream);
>      >? ? if (use_decorations)
>      >
>      > Here is the relevant disassembly code.
>      > ...prolog
>      > 0x7f76e3d0c223 <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+19>? ? ? mov? ? %rdi,%rbx
>      > 0x7f76e3d0c226 <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+22>? ? ? sub? ? $0x128,%rsp
>      > 0x7f76e3d0c22d <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+29>? ? ? mov? ? 0x28(%rdi),%r15
>      > 0x7f76e3d0c231 <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+33>? ? ? mov? ? 0x20(%rdi),%r12d
>      > 0x7f76e3d0c235 <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+37>? ? ? mov? ? %rdx,-0x148(%rbp)
>      > 0x7f76e3d0c23c <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+44>? ? ? mov? ? %r15,%rdi
>      > 0x7f76e3d0c23f <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+47>? ? ? mov? ? %fs:0x28,%rax
>      > 0x7f76e3d0c248 <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+56>? ? ? mov? ? %rax,-0x38(%rbp)
>      > 0x7f76e3d0c24c <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+60>? ? ? xor? ? %eax,%eax
>      > 0x7f76e3d0c24e <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+62>? ? ? callq? 0x7f76e3feb090 <os::flockfile(_IO_FILE*)>
>      > 0x7f76e3d0c253 <LogFileStreamOutput::write(LogDecorations const&,
>     char
>      > const*)+67>? ? ? test? ?%r12d,%r12d
>      >
>      >
>      > We can see that r15 = load 0x28(%rdi) and its value is bad.
>     however, in
>      > memory, Its value is correct. this->_stream is 0x55ea4d0f8d00.
>      >
>      > (gdb) p /x $r15
>      > $13 = 0xbabababababababa
>      >
>      > (gdb) p /x $rbx
>      > $27 = 0x55ea4d504bd0
>      >
>      > (gdb) x /1g $rbx + 0x28
>      > 0x55ea4d504bf8: 0x000055ea4d0f8d00
>      >
>      > In main thread, we can see that output->_stream is well defined.
>      >
>      > (gdb) p output
>      > $24 = (LogOutput *) 0x55ea4d504bd0
>      >
>      > (gdb) p ((LogFileOutput*)output)->_stream
>      > $23 = (FILE *) 0x55ea4d0f8d00
>      >
>      >
>      >
>     -------------------------------------------------------------------------
>      >
>      > Can I say it's a memory ordering issue on x86_64? TBH, I can't
>     explain
>      > how that happens.
>      >
>      > Early moment in main thread, LogFileOutput::initialize() was
>     called and
>      > _stream was initialized. After then, the program at least has
>     gone through:
>      >
>      > 1. Atomic::add (lock prefix instruction, which is implied store-load
>      > barrier?).
>      > 2. sem_wait/post (acquire-release semantics).
>      >
>      > Therefore, I believe the current thread must see the written value of
>      > LogFileOutput::initialize(). ie. _stream should be (FILE *)
>      > 0x55ea4d0f8d00, not 0xbababa...
>      >
>      > Last but not least question. To further understand this problem and
>      > verify patch, I think the key is to find a reproducible. Any
>     thoughts on
>      > how to reproduce this kinda of problem?? So far, I only came
>     across this
>      > crash once on my side. I used a docker image of Oracle Linux 7.9
>     (glibc
>      > 2.17) with cpuset 0~2.? Beside a core dump and a crash report, I
>     can't
>      > reproduce it anymore. I think I must overlook some important factors
>      > here.? Really appreciate some head-ups.
>      >
>      > I notice that Oracle is using 3-gen Zen architecture to run
>     tests. Is it
>      > anything different from conventional x86_64? In AMD's manual[1],
>     7.4.2,
>      > Table-3, here is the description about lock-prefix instruction.
>      >
>      > k? ? All loads and stores associated with the I/O and locked
>      > instructions complete to memory (no bufferedstores) before a load or
>      > store from a subsequent instruction is issued.
>      >
>      > It seems to me that it doesn't imply "bidirectional full memory
>     barrier"
>      > or storeload barrier. it just has acquire semantic. I read the story
>      > behind this change and Aleksey's article[2]. I'm just not sure the
>      > following code is equivalent to "mfence" on EPYC machines because
>     AMD's
>      > manual is different from Intel's.
>      >
>      > inline void OrderAccess::fence() {
>      >? ? ?// always use locked addl since mfence is sometimes expensive
>      > #ifdef AMD64
>      >? ? __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
>      > #else
>      >? ? __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
>      > #endif
>      >? ? compiler_barrier();
>      > }
>      >
>      >
>      > [1] https://www.amd.com/system/files/TechDocs/24593.pdf
>     <https://www.amd.com/system/files/TechDocs/24593.pdf>
>      > [2]
>      >
>     https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1
>     <https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1>
>      >
>      > thanks,
>      > --lx
>      >
>      >
>      >
> 

From david.holmes at oracle.com  Mon Jun 21 23:28:20 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 09:28:20 +1000
Subject: A question about memory order on x86_64
In-Reply-To: <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
 <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
Message-ID: <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>

On 22/06/2021 8:02 am, David Holmes wrote:
> On 22/06/2021 6:49 am, Liu Xin wrote:
>> hi, David,
>>
>> Thanks. This is my blindspot. Let me go through your description. 
>> There are 3 threads. M is the main thread which is doing 
>> logConfiguration changes.
>> A is the async log thread, which is flushing. L is a user thread which 
>> is emitting logs.
>>
>> M: flush1/sem_wait ---- ---- ---- ---- ---- ---- ---- flush1/sem_post 
>> ---- flush2/sem_wait ---- flush2/sem.post <http://sem.post> ---- 
>> delete_output() ----
>> L: ---- ---- enqueue(log1) ---- ---- ---- ---- ---- ---- ---- ---- 
>> ---- ----
>> A: ---- ---- ---- ---- ---- dequeue(log1) ---- run/sem_wait ---- ---- 
>> ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 
>> write_blocking(log1)
>>
>> This is the timeline you described, isn't it?
> 
> Probably close enough.
> 
>> A key missing information is that sem_wait() (POSIX semaphore) doesn't 
>> respect FIFO order.
>> I thought Thread-A has invoked run/sem_wait() first. If 
>> flush1/sem_post() is called, kernel must wake up thread A immediately. 
>> It may NOT? the case, right?
> 
> Right there are no guarantees that when M calls signal/post to wakeup A, 
> that A will actually get to run and consume the token and so return from 
> sem_wait. If the implementation is based on futex then it is likely 
> similar to mutex operation and the newly woken thread will contend with 
> all other threads to try and claim the semaphore. In such cases if M 
> calls sem_wait very shortly after sem_post then it will likely reclaim 
> the semaphore.
> 
>> It's possible that thread-A is descheduled and thread-M can keep 
>> going. Under the hook, I see that glibc implements sem_wait using 
>> syscall futex.
>>
>> In my test, I stupidly put two set_log_config() in a loop. Therefore, 
>> M invokes two flush() in a row!
>> https://github.com/openjdk/jdk/pull/4408/files#diff-25062d200033077d44dacb5aae6b8141316b4bc10149c061cf047fe7db250d98R306 
>> <https://github.com/openjdk/jdk/pull/4408/files#diff-25062d200033077d44dacb5aae6b8141316b4bc10149c061cf047fe7db250d98R306> 
>>
>>
>> Let me try to simulate this and see if I have a fix.
> 
> I'm beginning to think that the only safe thing to do here is to 
> lock-out configuration changes while any write is in progress.

But we can't do that as we could block indefinitely while writing.

Backing up a step lets ignore async logging for a moment. How does 
synchronous logging deal with this problem? What ensures that a log 
request can't use an output that is being concurrently deleted by a 
configuration change?

David

> David
> -----
> 
>> Thanks,
>> -lx
>>
>>
>>
>>
>> On Sun, Jun 20, 2021 at 6:54 PM David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? Hi Xin,
>>
>> ??? I'm looking at your code again and apologies if we covered this
>> ??? previously but I'm not seeing how things are supposed to work 
>> exactly.
>> ??? Looking at the write() function :
>>
>> ??? void AsyncLogWriter::write() {
>> ???? ? ?AsyncLogBuffer logs;
>> ???? ? ?bool own_io = false;
>>
>> ???? ? ?{ // critical region
>> ???? ? ? ?AsyncLogLocker locker;
>>
>> ???? ? ? ?_buffer.pop_all(&logs);
>> ???? ? ? ?// append meta-messages of dropped counters
>> ???? ? ? ?AsyncLogMapIterator dropped_counters_iter(logs);
>> ???? ? ? ?_stats.iterate(&dropped_counters_iter);
>> ???? ? ? ?own_io = _io_sem.trywait();
>> ???? ? ?}
>>
>> ???? ? ?LinkedListIterator<AsyncLogMessage> it(logs.head());
>> ???? ? ?if (!own_io) {
>> ???? ? ? ?_io_sem.wait();
>> ???? ? ?}
>>
>> ???? ? ?while (!it.is_empty()) {
>> ???? ? ? ?AsyncLogMessage* e = it.next();
>> ???? ? ? ?char* msg = e->message();
>>
>> ???? ? ? ?if (msg != nullptr) {
>> ???? ? ? ? ?e->output()->write_blocking(e->decorations(), msg);
>>
>> ??? Supposed that a flush() operation has called write() and it has 
>> reached
>> ??? the point where it is about to release the io_sem at the end and gets
>> ??? descheduled. Other threads then perform logging operations that 
>> include
>> ??? a specific output N. The async log thread executes the code above, 
>> and
>> ??? stashes those log messages off in the local "logs" and then blocks on
>> ??? io_sem_wait. Let the original flush release the io_sem, and a second
>> ??? flush() commence due to the log configuration update that will delete
>> ??? output N. That flush also completes and releases the io_sem. The 
>> async
>> ??? log thread now acquires io_sem and attempts to write to the output 
>> that
>> ??? was just deleted.
>>
>> ??? David
>> ??? -----
>>
>> ??? On 21/06/2021 6:50 am, Liu, Xin wrote:
>> ???? > Hi, Hotspot experts,
>> ???? >
>> ???? > I am debugging a PR which uses lock-free programming. David Holmes
>> ???? > helped me submit this patch to the internal regression 
>> infra(thanks a
>> ???? > lot). We got intermittent failures at tier4~7. There are two 
>> distinct
>> ???? > crash sights, but they're similar. I guess the reason is asynclog
>> ??? thread
>> ???? > observed different memory state from other threads.
>> ???? >
>> ???? > https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283
>> ??? <https://github.com/openjdk/jdk/pull/4408#issuecomment-863788283>
>> ???? >
>> ???? > I have spent a lot efforts on reproducing this problem. 
>> Eventually, I
>> ???? > got a crash in docker and luckily coredump file and hs_err report
>> ??? were
>> ???? > all saved.
>> ???? >
>> ???? > In core dump file, I see this stacktraces in asynclog thread.
>> ???? >
>> ???? > (gdb) bt
>> ???? > ...
>> ???? > #24 0x00007f76e1ab0e90 in flockfile () from /lib64/libc.so.6
>> ???? > #25 0x00007f76e3d0c253 in FileLocker (file=0xbabababababababa,
>> ???? > this=<synthetic pointer>) at
>> ???? > /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
>> ???? > #26 LogFileStreamOutput::write (this=0x55ea4d504bd0, 
>> decorations=...,
>> ???? > msg=0x7f7624079b00 "ConcurrentLogsite 3 emits a log") at
>> ???? > /jdk/src/hotspot/share/logging/logFileStreamOutput.cpp:125
>> ???? > #27 0x00007f76e3d0b572 in LogFileOutput::write_blocking
>> ???? > (this=0x55ea4d504bd0, decorations=..., msg=0x7f7624079b00
>> ???? > "ConcurrentLogsite 3 emits a log") at
>> ???? > /jdk/src/hotspot/share/logging/logFileOutput.cpp:308
>> ???? > #28 0x00007f76e3d05bbd in write (this=0x55ea4d2e1af0) at
>> ???? > /jdk/src/hotspot/share/logging/logAsyncWriter.hpp:106
>> ???? > #29 AsyncLogWriter::run (this=0x55ea4d2e1af0) at
>> ???? > /jdk/src/hotspot/share/logging/logAsyncWriter.cpp:163
>> ???? > #30 0x00007f76e44696a0 in Thread::call_run 
>> (this=0x55ea4d2e1af0) at
>> ???? > /jdk/src/hotspot/share/runtime/thread.cpp:394
>> ???? > #31 0x00007f76e3fdf9b4 in thread_native_entry
>> ??? (thread=0x55ea4d2e1af0) at
>> ???? > /jdk/src/hotspot/os/linux/os_linux.cpp:720
>> ???? > #32 0x00007f76e162cea5 in start_thread () from 
>> /lib64/libpthread.so.0
>> ???? > #33 0x00007f76e1b439fd in clone () from /lib64/libc.so.6
>> ???? >
>> ???? > The corresponding code is here. _stream is 0xbabababababababa?
>> ???? >
>> ???? > int LogFileStreamOutput::write(const LogDecorations& decorations,
>> ??? const
>> ???? > char* msg) {
>> ???? >? ? const bool use_decorations = !_decorators.is_empty();
>> ???? >
>> ???? >? ? int written = 0;
>> ???? >? ? FileLocker flocker(_stream);
>> ???? >? ? if (use_decorations)
>> ???? >
>> ???? > Here is the relevant disassembly code.
>> ???? > ...prolog
>> ???? > 0x7f76e3d0c223 <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+19>? ? ? mov? ? %rdi,%rbx
>> ???? > 0x7f76e3d0c226 <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+22>? ? ? sub? ? $0x128,%rsp
>> ???? > 0x7f76e3d0c22d <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+29>? ? ? mov? ? 0x28(%rdi),%r15
>> ???? > 0x7f76e3d0c231 <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+33>? ? ? mov? ? 0x20(%rdi),%r12d
>> ???? > 0x7f76e3d0c235 <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+37>? ? ? mov? ? %rdx,-0x148(%rbp)
>> ???? > 0x7f76e3d0c23c <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+44>? ? ? mov? ? %r15,%rdi
>> ???? > 0x7f76e3d0c23f <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+47>? ? ? mov? ? %fs:0x28,%rax
>> ???? > 0x7f76e3d0c248 <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+56>? ? ? mov? ? %rax,-0x38(%rbp)
>> ???? > 0x7f76e3d0c24c <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+60>? ? ? xor? ? %eax,%eax
>> ???? > 0x7f76e3d0c24e <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+62>? ? ? callq? 0x7f76e3feb090 <os::flockfile(_IO_FILE*)>
>> ???? > 0x7f76e3d0c253 <LogFileStreamOutput::write(LogDecorations const&,
>> ??? char
>> ???? > const*)+67>? ? ? test? ?%r12d,%r12d
>> ???? >
>> ???? >
>> ???? > We can see that r15 = load 0x28(%rdi) and its value is bad.
>> ??? however, in
>> ???? > memory, Its value is correct. this->_stream is 0x55ea4d0f8d00.
>> ???? >
>> ???? > (gdb) p /x $r15
>> ???? > $13 = 0xbabababababababa
>> ???? >
>> ???? > (gdb) p /x $rbx
>> ???? > $27 = 0x55ea4d504bd0
>> ???? >
>> ???? > (gdb) x /1g $rbx + 0x28
>> ???? > 0x55ea4d504bf8: 0x000055ea4d0f8d00
>> ???? >
>> ???? > In main thread, we can see that output->_stream is well defined.
>> ???? >
>> ???? > (gdb) p output
>> ???? > $24 = (LogOutput *) 0x55ea4d504bd0
>> ???? >
>> ???? > (gdb) p ((LogFileOutput*)output)->_stream
>> ???? > $23 = (FILE *) 0x55ea4d0f8d00
>> ???? >
>> ???? >
>> ???? >
>>     
>> -------------------------------------------------------------------------
>> ???? >
>> ???? > Can I say it's a memory ordering issue on x86_64? TBH, I can't
>> ??? explain
>> ???? > how that happens.
>> ???? >
>> ???? > Early moment in main thread, LogFileOutput::initialize() was
>> ??? called and
>> ???? > _stream was initialized. After then, the program at least has
>> ??? gone through:
>> ???? >
>> ???? > 1. Atomic::add (lock prefix instruction, which is implied 
>> store-load
>> ???? > barrier?).
>> ???? > 2. sem_wait/post (acquire-release semantics).
>> ???? >
>> ???? > Therefore, I believe the current thread must see the written 
>> value of
>> ???? > LogFileOutput::initialize(). ie. _stream should be (FILE *)
>> ???? > 0x55ea4d0f8d00, not 0xbababa...
>> ???? >
>> ???? > Last but not least question. To further understand this problem 
>> and
>> ???? > verify patch, I think the key is to find a reproducible. Any
>> ??? thoughts on
>> ???? > how to reproduce this kinda of problem?? So far, I only came
>> ??? across this
>> ???? > crash once on my side. I used a docker image of Oracle Linux 7.9
>> ??? (glibc
>> ???? > 2.17) with cpuset 0~2.? Beside a core dump and a crash report, I
>> ??? can't
>> ???? > reproduce it anymore. I think I must overlook some important 
>> factors
>> ???? > here.? Really appreciate some head-ups.
>> ???? >
>> ???? > I notice that Oracle is using 3-gen Zen architecture to run
>> ??? tests. Is it
>> ???? > anything different from conventional x86_64? In AMD's manual[1],
>> ??? 7.4.2,
>> ???? > Table-3, here is the description about lock-prefix instruction.
>> ???? >
>> ???? > k? ? All loads and stores associated with the I/O and locked
>> ???? > instructions complete to memory (no bufferedstores) before a 
>> load or
>> ???? > store from a subsequent instruction is issued.
>> ???? >
>> ???? > It seems to me that it doesn't imply "bidirectional full memory
>> ??? barrier"
>> ???? > or storeload barrier. it just has acquire semantic. I read the 
>> story
>> ???? > behind this change and Aleksey's article[2]. I'm just not sure the
>> ???? > following code is equivalent to "mfence" on EPYC machines because
>> ??? AMD's
>> ???? > manual is different from Intel's.
>> ???? >
>> ???? > inline void OrderAccess::fence() {
>> ???? >? ? ?// always use locked addl since mfence is sometimes expensive
>> ???? > #ifdef AMD64
>> ???? >? ? __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", 
>> "memory");
>> ???? > #else
>> ???? >? ? __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", 
>> "memory");
>> ???? > #endif
>> ???? >? ? compiler_barrier();
>> ???? > }
>> ???? >
>> ???? >
>> ???? > [1] https://www.amd.com/system/files/TechDocs/24593.pdf
>> ??? <https://www.amd.com/system/files/TechDocs/24593.pdf>
>> ???? > [2]
>> ???? >
>>     
>> https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1 
>>
>>     
>> <https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_footnote_1> 
>>
>> ???? >
>> ???? > thanks,
>> ???? > --lx
>> ???? >
>> ???? >
>> ???? >
>>

From xxinliu at amazon.com  Mon Jun 21 23:56:18 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Mon, 21 Jun 2021 16:56:18 -0700
Subject: A question about memory order on x86_64
In-Reply-To: <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
 <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
 <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>
Message-ID: <a26d756f-4c69-3e01-95a1-6ae82a85a6b8@amazon.com>

Hi, David,

LogConfiguration::configure_output() is intriguing. That's why I try to
explain/comment it in that PR.

For sync logging, the RCU reader counter remains > 0 in "writing"
period. LogOutputList::Iterator is a RAII class. Its ctor calls
increase_readers() and dtor calls decrease_readers().
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logTagSet.cpp#L77

When the users decide to disable a LogOutput, they need to adjust levels
first. eg. change tagset 'gc' from DEBUG to OFF. There's a RCU
synchronization "wait_until_no_readers()" inside of
LogOutputList::update_output_level().
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L241

When this function returns, it means that all logsites have seen that
tagset's level change and all ongoing "writings" have done because
_active_readers was once back to zero. There're 200+ tagsets. Each
changed tagset needs a RCU synchronization.

void LogOutputList::wait_until_no_readers() const {
  OrderAccess::storeload();
  while (_active_readers != 0) {
    // Busy wait
  }
}

Of course, logsites are still active after wait_until_no_readers(), but
they have seen new levels for the tagsets. They won't emit logs to the
deleting LogOutput. Therefore, it's safe to delete it.


I would like to make async log a natural extension of current lock-free
mechanism. The RCU counters only control "enqueuing" periods instead of
"writing" periods. As long as flush() works, it's still correct.

thanks,
--lx



On 6/21/21 4:28 PM, David Holmes wrote:
> But we can't do that as we could block indefinitely while writing.
> 
> Backing up a step lets ignore async logging for a moment. How does
> synchronous logging deal with this problem? What ensures that a log
> request can't use an output that is being concurrently deleted by a
> configuration change?

From dholmes at openjdk.java.net  Tue Jun 22 00:02:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 00:02:37 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

Looks fine apart from use of INT32_MIN instead of INT_MIN.

Thanks,
David

src/hotspot/share/runtime/objectMonitor.cpp line 548:

> 546:     set_owner_from(NULL, DEFLATER_MARKER);
> 547:     assert(contentions() >= 0, "must be non-negative: contentions=%d", contentions());
> 548:     _contentions = INT32_MIN; // minimum negative int

INT_MIN (unless you want to change the type to int32_t)

src/hotspot/share/runtime/objectMonitor.cpp line 575:

> 573:     // Make a zero contentions field negative to force any contending threads
> 574:     // to retry. This is the second part of the async deflation dance.
> 575:     if (Atomic::cmpxchg(&_contentions, (int)0, INT32_MIN) != 0) {

INT_MIN

Do we really need the cast on 0?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From dholmes at openjdk.java.net  Tue Jun 22 00:15:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 00:15:33 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v4]
In-Reply-To: <dLXZ4E9xptK3pKFpfjG0bq8ohETgRpY33K4GHtgz-Yc=.c7681e38-95ba-4dc5-a68e-2960b5ffc87c@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <dLXZ4E9xptK3pKFpfjG0bq8ohETgRpY33K4GHtgz-Yc=.c7681e38-95ba-4dc5-a68e-2960b5ffc87c@github.com>
Message-ID: <3toSuKMsG7qftiYd1okq1YP0ma25NYPBk2IYlTidwjY=.03ef3cc5-0564-401c-bd42-2e3396d0b30b@github.com>

On Mon, 21 Jun 2021 17:11:05 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
>> 
>> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
>> 
>> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
>> 
>> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   split verify_legal_method_signature() into two methods

Hi Harold,

Changes look good - thanks.

David

src/hotspot/share/classfile/classFileParser.cpp line 5058:

> 5056:     // make sure caller's args_size will be less than 0 even for non-static
> 5057:     // method so it will be recomputed in compute_size_of_parameters().
> 5058:     return;

The comment makes no sense with a void return type.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4497

From david.holmes at oracle.com  Tue Jun 22 00:21:14 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 10:21:14 +1000
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <e78d48fa-36f8-e24b-2009-8c1798b510ed@oracle.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
 <kctvOq6V6i3nX77Vr59S30O6g9DnUB9eqZ_jCTYcRfc=.0893c1a5-d97e-4254-970e-25206bf1c1df@github.com>
 <e78d48fa-36f8-e24b-2009-8c1798b510ed@oracle.com>
Message-ID: <acc04674-c62a-930d-12b0-cc401c862546@oracle.com>

On 22/06/2021 1:41 am, Coleen Phillimore wrote:
> On 6/21/21 12:28 AM, David Holmes wrote:
>> On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore 
>> <coleenp at openjdk.org> wrote:
>>
>>> The handshake code tests if the JavaThread->is_exiting or that the 
>>> threadObj() is null. Ever since JDK-8244997, once the JavaThread is 
>>> running, the _threadObj won't be null until JavaThread is destroyed. 
>>> So testing is_exiting is all you need to do.
>>> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 
>>> so removing this unnecessary test allows writing gtests for handshakes.
>>>
>>> Tested with tier1-6.
>> Hi Coleen,
>>
>> What about an attaching thread that hits a handshake when trying to 
>> allocate the java.lang.Thread object?
> 
> The attaching thread can't be handshake because it hasn't been added to 
> the Threads list until threadObj is initialized.? As far as I can tell, 
> you can't handshake a thread that's not on the list.

I'm not sure what code you are looking at but attach_current_thread does:

   // This thread will not do a safepoint check, since it has
   // not been added to the Thread list yet.
   { MutexLocker ml(Threads_lock);
     thread->set_active_handles(JNIHandleBlock::allocate_block());
     Threads::add(thread, daemon);
   }

and the thread is now on the threads-list; then it does:

  thread->allocate_threadObj(thread_group, thread_name, daemon, THREAD);

after that. And that code does:

   instanceHandle thread_oop = ik->allocate_instance_handle(CHECK);

   java_lang_Thread::set_thread(thread_oop(), this);
   java_lang_Thread::set_priority(thread_oop(), NormPriority);
   set_threadObj(thread_oop());

The thread must be on the threads-list and able to participate in 
safepoints because it is going to allocate a Java object. After this 
point it also executes Java code - so again absolutely must be on the 
threads-list already.

David
-----

> Coleen
> 
>>
>> David
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4512
> 

From david.holmes at oracle.com  Tue Jun 22 00:39:25 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 10:39:25 +1000
Subject: [EXTERNAL] A question about memory order on x86_64
In-Reply-To: <a26d756f-4c69-3e01-95a1-6ae82a85a6b8@amazon.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
 <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
 <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>
 <a26d756f-4c69-3e01-95a1-6ae82a85a6b8@amazon.com>
Message-ID: <4c5316c5-4baa-80a2-656d-ffab7e74ff3a@oracle.com>

On 22/06/2021 9:56 am, Liu, Xin wrote:
> Hi, David,
> 
> LogConfiguration::configure_output() is intriguing. That's why I try to
> explain/comment it in that PR.
> 
> For sync logging, the RCU reader counter remains > 0 in "writing"
> period. LogOutputList::Iterator is a RAII class. Its ctor calls
> increase_readers() and dtor calls decrease_readers().
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logTagSet.cpp#L77
> 
> When the users decide to disable a LogOutput, they need to adjust levels
> first. eg. change tagset 'gc' from DEBUG to OFF. There's a RCU
> synchronization "wait_until_no_readers()" inside of
> LogOutputList::update_output_level().
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L241
> 
> When this function returns, it means that all logsites have seen that
> tagset's level change and all ongoing "writings" have done because
> _active_readers was once back to zero. There're 200+ tagsets. Each
> changed tagset needs a RCU synchronization.
> 
> void LogOutputList::wait_until_no_readers() const {
>    OrderAccess::storeload();
>    while (_active_readers != 0) {
>      // Busy wait
>    }
> }
> 
> Of course, logsites are still active after wait_until_no_readers(), but
> they have seen new levels for the tagsets. They won't emit logs to the
> deleting LogOutput. Therefore, it's safe to delete it.

So they essentially lock out the change while they are writing - which 
means when the writing could block indefinitely then the change is also 
blocked indefinitely:

void LogTagSet::log(LogLevelType level, const char* msg) {
   LogDecorations decorations(level, *this, _decorators);
   for (LogOutputList::Iterator it = _output_list.iterator(level); it != 
_output_list.end(); it++) {
     (*it)->write(decorations, msg);
   }
}

> I would like to make async log a natural extension of current lock-free
> mechanism. The RCU counters only control "enqueuing" periods instead of
> "writing" periods. As long as flush() works, it's still correct.

Where is AsyncLogWriter::write participating in this RCU mechanism? The 
AsyncLogMessages that were enqueued, and have now been dequeued ready to 
be written, have already captured their "output", but there is nothing 
to protect those outputs. You can't guarantee that the flush() call 
handles all pre-existing enqueued messages, before that thread deletes 
the output. You would have to ensure that the write() from flush() waits 
for the AsyncLogWriter thread to complete any in-progress write() call 
before the flushing write() proceeds. I think you need to hold the 
io_sem across the entire write() to ensure it is executed atomically (we 
just need to make sure that can't lead to any deadlock scenarios with 
the other locking mechanisms in use.

David

> thanks,
> --lx
> 
> 
> 
> On 6/21/21 4:28 PM, David Holmes wrote:
>> But we can't do that as we could block indefinitely while writing.
>>
>> Backing up a step lets ignore async logging for a moment. How does
>> synchronous logging deal with this problem? What ensures that a log
>> request can't use an output that is being concurrently deleted by a
>> configuration change?

From stuefe at openjdk.java.net  Tue Jun 22 04:16:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 22 Jun 2021 04:16:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <zOXHOnYTbK_2ZUHoW8j1TYqTR_0d2sxW9SX--Qjtp9Y=.a26d9a8d-07c4-4336-a2b2-87b538be379d@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

LGTM

src/hotspot/share/runtime/objectMonitor.hpp line 244:

> 242:     int cnts = contentions(); // read once
> 243:     if (cnts > 0) {
> 244:       ret_code |= intptr_t(cnts);

I know it has nothing to do with your patch, but I am just curious. IIUC this is a strange way of saying "if A!=0 || B!=0 || C!=0..." . Is this for performance reasons? Also, why the "if (cnts > 0)", would that not be superfluous?

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From simonis at openjdk.java.net  Tue Jun 22 07:39:29 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 22 Jun 2021 07:39:29 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <MIfqqo5mQ9wHPGoM7-wFoV2hNe6sRy66ez1kdZKKqW8=.c443757d-eb32-427a-b72d-5dd2079c1429@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

src/hotspot/os/linux/trimCHeapDCmd.cpp line 70:

> 68:   _output->print_raw(ss_report.base());
> 69:   log_info(os)("malloc_trim: ");
> 70:   log_info(os)("%s", ss_report.base());

Might also make sense to put this into a single log line like `log_info(os)("malloc_trim:\n%s", ss_report.base());` to get something like:

[139,068s][info][os] malloc_trim:
Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)
Swap before: 0k, after: 0k, (0k)

instead of:

[139,068s][info][os] malloc_trim:
[139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)
Swap before: 0k, after: 0k, (0k)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From ddong at openjdk.java.net  Tue Jun 22 08:31:31 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 22 Jun 2021 08:31:31 GMT
Subject: Integrated: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <bQBWTWtje17X_t_Ou4sC7Dr-xVu0GUrsRyyFwJL-Zbk=.def46a68-fb1e-4834-8d6a-5da356dde986@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

This pull request has now been integrated.

Changeset: 1f0ea7c3
Author:    Denghui Dong <ddong at openjdk.org>
Committer: Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f0ea7c3d62221405de982ba484c0ee985fa9d7b
Stats:     51 lines in 8 files changed: 5 ins; 33 del; 13 mod

8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From david.holmes at oracle.com  Tue Jun 22 11:20:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 21:20:43 +1000
Subject: Integrated: 8268857: Merge VM_PrintJNI and VM_PrintThreads and
 remove the unused field 'is_deadlock' of DeadlockCycle
In-Reply-To: <bQBWTWtje17X_t_Ou4sC7Dr-xVu0GUrsRyyFwJL-Zbk=.def46a68-fb1e-4834-8d6a-5da356dde986@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <bQBWTWtje17X_t_Ou4sC7Dr-xVu0GUrsRyyFwJL-Zbk=.def46a68-fb1e-4834-8d6a-5da356dde986@github.com>
Message-ID: <12a4cc5e-aa57-ab73-37a3-c0fcc656d9d0@oracle.com>

Hi,

Please note that hotspot changes require two reviews before integrating 
(unless a trivial change).

David


On 22/06/2021 6:31 pm, Denghui Dong wrote:
> On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:
> 
>> Hi,
>>
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>>
>> `jstack` is a very common command, even in the production environment.
>>
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
> 
> This pull request has now been integrated.
> 
> Changeset: 1f0ea7c3
> Author:    Denghui Dong <ddong at openjdk.org>
> Committer: Yi Yang <yyang at openjdk.org>
> URL:       https://git.openjdk.java.net/jdk/commit/1f0ea7c3d62221405de982ba484c0ee985fa9d7b
> Stats:     51 lines in 8 files changed: 5 ins; 33 del; 13 mod
> 
> 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle
> 
> Reviewed-by: dholmes
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4504
> 

From david.holmes at oracle.com  Tue Jun 22 11:32:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 21:32:07 +1000
Subject: [EXTERNAL] A question about memory order on x86_64
In-Reply-To: <4c5316c5-4baa-80a2-656d-ffab7e74ff3a@oracle.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
 <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
 <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>
 <a26d756f-4c69-3e01-95a1-6ae82a85a6b8@amazon.com>
 <4c5316c5-4baa-80a2-656d-ffab7e74ff3a@oracle.com>
Message-ID: <e5b3f9a1-662f-989a-31c4-eefd3e77e147@oracle.com>

On 22/06/2021 10:39 am, David Holmes wrote:
> On 22/06/2021 9:56 am, Liu, Xin wrote:
>> Hi, David,
>>
>> LogConfiguration::configure_output() is intriguing. That's why I try to
>> explain/comment it in that PR.
>>
>> For sync logging, the RCU reader counter remains > 0 in "writing"
>> period. LogOutputList::Iterator is a RAII class. Its ctor calls
>> increase_readers() and dtor calls decrease_readers().
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logTagSet.cpp#L77 
>>
>>
>> When the users decide to disable a LogOutput, they need to adjust levels
>> first. eg. change tagset 'gc' from DEBUG to OFF. There's a RCU
>> synchronization "wait_until_no_readers()" inside of
>> LogOutputList::update_output_level().
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L241 
>>
>>
>> When this function returns, it means that all logsites have seen that
>> tagset's level change and all ongoing "writings" have done because
>> _active_readers was once back to zero. There're 200+ tagsets. Each
>> changed tagset needs a RCU synchronization.
>>
>> void LogOutputList::wait_until_no_readers() const {
>> ?? OrderAccess::storeload();
>> ?? while (_active_readers != 0) {
>> ???? // Busy wait
>> ?? }
>> }
>>
>> Of course, logsites are still active after wait_until_no_readers(), but
>> they have seen new levels for the tagsets. They won't emit logs to the
>> deleting LogOutput. Therefore, it's safe to delete it.
> 
> So they essentially lock out the change while they are writing - which 
> means when the writing could block indefinitely then the change is also 
> blocked indefinitely:
> 
> void LogTagSet::log(LogLevelType level, const char* msg) {
>  ? LogDecorations decorations(level, *this, _decorators);
>  ? for (LogOutputList::Iterator it = _output_list.iterator(level); it != 
> _output_list.end(); it++) {
>  ??? (*it)->write(decorations, msg);
>  ? }
> }
> 
>> I would like to make async log a natural extension of current lock-free
>> mechanism. The RCU counters only control "enqueuing" periods instead of
>> "writing" periods. As long as flush() works, it's still correct.
> 
> Where is AsyncLogWriter::write participating in this RCU mechanism? The 
> AsyncLogMessages that were enqueued, and have now been dequeued ready to 
> be written, have already captured their "output", but there is nothing 
> to protect those outputs. You can't guarantee that the flush() call 
> handles all pre-existing enqueued messages, before that thread deletes 
> the output. You would have to ensure that the write() from flush() waits 
> for the AsyncLogWriter thread to complete any in-progress write() call 
> before the flushing write() proceeds. I think you need to hold the 
> io_sem across the entire write() to ensure it is executed atomically (we 
> just need to make sure that can't lead to any deadlock scenarios with 
> the other locking mechanisms in use.

I made the change to hold the io_sem for all of write() and the tests 
passed in tiers 6 and 7.

David
-----

> David
> 
>> thanks,
>> --lx
>>
>>
>>
>> On 6/21/21 4:28 PM, David Holmes wrote:
>>> But we can't do that as we could block indefinitely while writing.
>>>
>>> Backing up a step lets ignore async logging for a moment. How does
>>> synchronous logging deal with this problem? What ensures that a log
>>> request can't use an output that is being concurrently deleted by a
>>> configuration change?

From ddong at openjdk.java.net  Tue Jun 22 11:45:31 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 22 Jun 2021 11:45:31 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <S9NEFwpHrHzzOep8i-7hvzxJuVh5d9Pxgk62KAIgOI4=.d048f552-6450-443b-9148-347ad7efdf8a@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [serviceability-dev](mailto:serviceability-dev at mail.openjdk.java.net):_
> 
> Hi,
> 
> Please note that hotspot changes require two reviews before integrating
> (unless a trivial change).
> 
> David
> 
> On 22/06/2021 6:31 pm, Denghui Dong wrote:

Sorry about this,  I will be more aware next time.

Denghui.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From hseigel at openjdk.java.net  Tue Jun 22 12:34:22 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 22 Jun 2021 12:34:22 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v5]
In-Reply-To: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
Message-ID: <y8jrWW1Cs-3hoBv61y23THQ_7OzAAAKwWRgSNpxALfY=.3dee752e-8e4e-4f24-ac2a-60c9f4f3ea3b@github.com>

> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
> 
> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
> 
> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
> 
> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  remove senseless comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4497/files
  - new: https://git.openjdk.java.net/jdk/pull/4497/files/b42efc40..e38768c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4497&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4497/head:pull/4497

PR: https://git.openjdk.java.net/jdk/pull/4497

From hseigel at openjdk.java.net  Tue Jun 22 12:34:25 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 22 Jun 2021 12:34:25 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v4]
In-Reply-To: <3toSuKMsG7qftiYd1okq1YP0ma25NYPBk2IYlTidwjY=.03ef3cc5-0564-401c-bd42-2e3396d0b30b@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <dLXZ4E9xptK3pKFpfjG0bq8ohETgRpY33K4GHtgz-Yc=.c7681e38-95ba-4dc5-a68e-2960b5ffc87c@github.com>
 <3toSuKMsG7qftiYd1okq1YP0ma25NYPBk2IYlTidwjY=.03ef3cc5-0564-401c-bd42-2e3396d0b30b@github.com>
Message-ID: <s6uv_odvYKzY7k-X8dWAQt9-honczreqGgf2mVmTpWM=.b70499ec-8472-4e8d-ad70-e6c14f2d7bcc@github.com>

On Tue, 22 Jun 2021 00:02:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   split verify_legal_method_signature() into two methods
>
> src/hotspot/share/classfile/classFileParser.cpp line 5058:
> 
>> 5056:     // make sure caller's args_size will be less than 0 even for non-static
>> 5057:     // method so it will be recomputed in compute_size_of_parameters().
>> 5058:     return;
> 
> The comment makes no sense with a void return type.

Thanks David!  I deleted the bogus comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From cgo at openjdk.java.net  Tue Jun 22 13:41:50 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Tue, 22 Jun 2021 13:41:50 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
Message-ID: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>

The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.

I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.

In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

-------------

Commit messages:
 - Fix test case for client VMs.

Changes: https://git.openjdk.java.net/jdk/pull/4558/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4558&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269135
  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4558/head:pull/4558

PR: https://git.openjdk.java.net/jdk/pull/4558

From dcubed at openjdk.java.net  Tue Jun 22 14:07:35 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 14:07:35 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <nUB1_-2wnpJWo3mEbgRSewonyTyuI0SA3GlSLpAOcIY=.93613c5a-895d-4a15-9c1c-8191cb903e87@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

This PR should also have waiting for a review from the Serviceability team.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From dcubed at openjdk.java.net  Tue Jun 22 14:16:25 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 14:16:25 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <RD4vtbT2MDITQ-2AO0ileD-6JiumXBRNFRz-b2VPJho=.abc35cca-9919-44a7-bf49-c295cad00a25@github.com>

On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

@dholmes-ora - This one might interest you since it is a Nestmates test...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4558

From coleenp at openjdk.java.net  Tue Jun 22 14:39:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 14:39:32 GMT
Subject: Withdrawn: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <mgKf62uvCA_6NGJHjFSnId4pdEq-EqKjugq1MjBtNcA=.9eeae34e-0b16-433c-87ea-2be77af59a19@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From coleenp at openjdk.java.net  Tue Jun 22 14:39:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 14:39:32 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <eXXwjQ_4SG4jRQv36t3S3qgppcet32azVU7o6dZ4TV8=.58cfbf7d-4b41-4f05-8a7b-f4fc9c926180@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

I am looking at all the threads we create in the vm like the ServiceThread (look for Threads::add()), but not attach_current_thread in jni.  You're right, we have to make this thread safepoint here.
I wonder why some threads we create call ThreadGroup.add and some don't.  There's lots of duplicate code that's slightly different for each.
Unfortunately now I need a fix for JDK-8215948, hopefully without another duplicate copy of this thread creation code so I can write my handshake test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From coleenp at openjdk.java.net  Tue Jun 22 14:56:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 14:56:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <zOXHOnYTbK_2ZUHoW8j1TYqTR_0d2sxW9SX--Qjtp9Y=.a26d9a8d-07c4-4336-a2b2-87b538be379d@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <zOXHOnYTbK_2ZUHoW8j1TYqTR_0d2sxW9SX--Qjtp9Y=.a26d9a8d-07c4-4336-a2b2-87b538be379d@github.com>
Message-ID: <VzFCZDPtNTlDYXmbzL0f5EL1is8wUp7KCMSw2W3pKcw=.2cc12d3e-dcc0-4417-b82a-800828a56174@github.com>

On Tue, 22 Jun 2021 04:09:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.hpp line 244:
> 
>> 242:     int cnts = contentions(); // read once
>> 243:     if (cnts > 0) {
>> 244:       ret_code |= intptr_t(cnts);
> 
> I know it has nothing to do with your patch, but I am just curious. IIUC this is a strange way of saying "if A!=0 || B!=0 || C!=0..." . Is this for performance reasons? Also, why the "if (cnts > 0)", would that not be superfluous?

I think this code exists like this from when is_busy returned an uintptr_t.  It should be nicely rewritten with if != 0s now and likely would have better performance.  I won't do it with this change because these fields are volatile and I think should have Atomic::loads, which would lead to a lot of discussion that should happen independently.  I'll file an RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From rrich at openjdk.java.net  Tue Jun 22 15:16:34 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 22 Jun 2021 15:16:34 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v4]
In-Reply-To: <WvSUdGuMxCXRGZlRejUQoqo9VuURAZBqI4yVAB9sYw4=.5da37a9f-feff-4e8d-bdd4-54b917e16801@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <nTDfq0Lip-CwX9J-m0W8pRagCJVlk5D8i57AcSqTYVA=.0c287330-b163-48ca-9842-f6730c8f57cb@github.com>
 <vLH09NOV0vp8n0F_EHxLnzcayPSC5e_EvHIBMB4qH6c=.bbf33968-625e-46ca-bd47-cb8dcc0e75df@github.com>
 <WvSUdGuMxCXRGZlRejUQoqo9VuURAZBqI4yVAB9sYw4=.5da37a9f-feff-4e8d-bdd4-54b917e16801@github.com>
Message-ID: <6ro5movKH_OguGNNPICzLLJYy7Q_IHA169XBbTdWXdI=.92b036de-fbc2-4845-bd13-410c9e68f745@github.com>

On Mon, 21 Jun 2021 13:58:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> 
> 
> > No issues from my own testing. Broader test coverage on all platforms is expected tomorrow.
>
>  Great, I'll wait for that. Thanks for all the testing Richard!

Tests look fine. Also on s390. Unfortunately on ppc64le the tests didn't succeed because of another change. I'd suggest to wait one more day if you don't mind.

Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From dcubed at openjdk.java.net  Tue Jun 22 15:50:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 15:50:34 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
Message-ID: <4UYewAilWk6FSZCLNoXOnrRrxrT_6wJoLKB4P1xHn9M=.637c7157-9dd5-4e24-8c3d-95c890471c67@github.com>

On Mon, 21 Jun 2021 23:56:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 575:
> 
>> 573:     // Make a zero contentions field negative to force any contending threads
>> 574:     // to retry. This is the second part of the async deflation dance.
>> 575:     if (Atomic::cmpxchg(&_contentions, (int)0, INT32_MIN) != 0) {
> 
> INT_MIN
> 
> Do we really need the cast on 0?

The original cast of `(jint)0` was to get the right `cmpxchg()` selected.
I _think_ that with the switch to INT32_MIN, a regular `0` instead of `(int)0`
should compile.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From dcubed at openjdk.java.net  Tue Jun 22 15:50:32 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 15:50:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <p8tU9Nge_Qtgxwi-SjDFcXOoQgwT7jBPSgsDdauGvnM=.90e5bc2e-9c0e-4e78-9074-b0701982f7b9@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

Changes requested by dcubed (Reviewer).

src/hotspot/share/runtime/objectMonitor.hpp line 151:

> 149:   #define DEFLATER_MARKER reinterpret_cast<void*>(-1)
> 150:   void* volatile _owner;            // pointer to owning thread OR BasicLock
> 151:   volatile uintptr_t _previous_owner_tid;  // thread id of the previous owner of the monitor

Since you are changing the type for `_previous_owner_tid`, you also
need to change the `DEFINE_PAD_MINUS_SIZE` below:


  DEFINE_PAD_MINUS_SIZE(1, OM_CACHE_LINE_SIZE, sizeof(void* volatile) +
                        sizeof(volatile uintptr_t));

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From pchilanomate at openjdk.java.net  Tue Jun 22 15:52:34 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Tue, 22 Jun 2021 15:52:34 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v5]
In-Reply-To: <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
Message-ID: <z4J6Zz83-MpkJUuqKj8sgJXODKWLqhaAj-aANys4aGg=.893076f1-a486-41d2-aafc-1a0fd9355823@github.com>

On Mon, 21 Jun 2021 14:49:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Un-ProblemList serviceability tests (8268574 and 8268644)

Hi Richard,
> 
> Tests look fine. Also on s390. Unfortunately on ppc64le the tests didn't succeed because of another change. I'd suggest to wait one more day if you don't mind.

No problem, let me know when tests complete successfully.

Thanks again!

Patricio

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From coleenp at openjdk.java.net  Tue Jun 22 16:00:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:00:33 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
Message-ID: <6EHUis07nR1ZMpj3PrWeuE4HVX_4g6TNjdMtqGwm7vw=.53576f80-f0df-41d9-8102-5466652f6f99@github.com>

On Mon, 21 Jun 2021 23:55:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 548:
> 
>> 546:     set_owner_from(NULL, DEFLATER_MARKER);
>> 547:     assert(contentions() >= 0, "must be non-negative: contentions=%d", contentions());
>> 548:     _contentions = INT32_MIN; // minimum negative int
> 
> INT_MIN (unless you want to change the type to int32_t)

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Tue Jun 22 16:00:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:00:33 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <4UYewAilWk6FSZCLNoXOnrRrxrT_6wJoLKB4P1xHn9M=.637c7157-9dd5-4e24-8c3d-95c890471c67@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
 <4UYewAilWk6FSZCLNoXOnrRrxrT_6wJoLKB4P1xHn9M=.637c7157-9dd5-4e24-8c3d-95c890471c67@github.com>
Message-ID: <Wy8PgeGaureaDmKkg6As1besz18mEKQMYt5XArHL1UU=.f027be5f-b0cd-42b9-b011-03ec9e2c88f6@github.com>

On Tue, 22 Jun 2021 15:43:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 575:
>> 
>>> 573:     // Make a zero contentions field negative to force any contending threads
>>> 574:     // to retry. This is the second part of the async deflation dance.
>>> 575:     if (Atomic::cmpxchg(&_contentions, (int)0, INT32_MIN) != 0) {
>> 
>> INT_MIN
>> 
>> Do we really need the cast on 0?
>
> The original cast of `(jint)0` was to get the right `cmpxchg()` selected.
> I _think_ that with the switch to INT32_MIN, a regular `0` instead of `(int)0`
> should compile.

Yes, changing to INT_MIN is more correct and I don't need the cast to int now for zero.  Recompiling on all platforms, including the picky ones for verification.  Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Tue Jun 22 16:00:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:00:34 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <p8tU9Nge_Qtgxwi-SjDFcXOoQgwT7jBPSgsDdauGvnM=.90e5bc2e-9c0e-4e78-9074-b0701982f7b9@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <p8tU9Nge_Qtgxwi-SjDFcXOoQgwT7jBPSgsDdauGvnM=.90e5bc2e-9c0e-4e78-9074-b0701982f7b9@github.com>
Message-ID: <t5naKSkUBGPqWs3fKhVcdNHkjHj4AzmpDGZgM6_2BSM=.8df057cd-bec4-49da-a60c-c1fa484c9f04@github.com>

On Tue, 22 Jun 2021 15:45:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.hpp line 151:
> 
>> 149:   #define DEFLATER_MARKER reinterpret_cast<void*>(-1)
>> 150:   void* volatile _owner;            // pointer to owning thread OR BasicLock
>> 151:   volatile uintptr_t _previous_owner_tid;  // thread id of the previous owner of the monitor
> 
> Since you are changing the type for `_previous_owner_tid`, you also
> need to change the `DEFINE_PAD_MINUS_SIZE` below:
> 
> 
>   DEFINE_PAD_MINUS_SIZE(1, OM_CACHE_LINE_SIZE, sizeof(void* volatile) +
>                         sizeof(volatile uintptr_t));

Okay, yes, thank you for pointing this out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From github.com+42899633+eastig at openjdk.java.net  Tue Jun 22 16:49:31 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 22 Jun 2021 16:49:31 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <n9a7LTpT6SQUl17LKrB5U1NEMnbPVpgq-WzUXCYzqG8=.1454362d-829a-4f1b-abf7-23c9bd006342@github.com>

On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 117:

> 115:             optimizationLevel = CompilerWhiteBoxTest.COMP_LEVEL_SIMPLE;
> 116:         }
> 117:         wb.enqueueMethodForCompilation(cons,  optimizationLevel);

It might be worth to check the value `enqueueMethodForCompilation` returns.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4558

From xliu at openjdk.java.net  Tue Jun 22 16:50:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 22 Jun 2021 16:50:16 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v6]
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <houOltaq5lrYR4NyfVvomVstB9N6Z5ddCEP87RPQds8=.8ad1a37a-c504-477f-b66b-827ed51a2de1@github.com>

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

Xin Liu 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 ten additional commits since the last revision:

 - AsyncLogWrite::flush() uses a synchronization token and wait for completion.
   
   This patch serializes all flush() calls in one thread.
 - Merge branch 'master' into JDK-8267952
 - Revert "Use Atomic::load/store for decorators."
   
   This reverts commit f279f2639bc638a35ae6c716987feb22d36a2a07.
 - Revert "Fix VC++ warning C4099"
   
   This reverts commit 157a065876850df784d9e7c034e106f4532b607a.
 - Fix VC++ warning C4099
 - Use Atomic::load/store for decorators.
   
   This patch also installed a sanity check which will assert that
   LogOutput::_decorators is subset of LogDecocrations. It will disclose
   more information if the assertion fails.
 - Merge branch 'master' into JDK-8267952
 - Add comments in LogTagSet::log().
 - 8267952: async logging supports to dynamically change tags and decorators

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4408/files
  - new: https://git.openjdk.java.net/jdk/pull/4408/files/157a0658..ae3ae36d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=04-05

  Stats: 18757 lines in 334 files changed: 11361 ins; 6472 del; 924 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408

PR: https://git.openjdk.java.net/jdk/pull/4408

From github.com+42899633+eastig at openjdk.java.net  Tue Jun 22 17:05:27 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 22 Jun 2021 17:05:27 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <_se59EuybrnEOk47_CxwFeP2d0SpyCJt_8lOTxlYi3Y=.a4f6307d-e37e-4c2e-804c-57b21a5eadb2@github.com>

On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 116:

> 114:         if (!wb.isC2OrJVMCIIncluded()) {
> 115:             optimizationLevel = CompilerWhiteBoxTest.COMP_LEVEL_SIMPLE;
> 116:         }

I think it is better to check whether COMP_LEVEL_FULL_OPTIMIZATION is supported:

if (!wb.isMethodCompilable(cons, optimizationLevel)) {
  optimizationLevel = CompilerWhiteBoxTest.COMP_LEVEL_ANY;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/4558

From navy.xliu at gmail.com  Tue Jun 22 17:11:41 2021
From: navy.xliu at gmail.com (Liu Xin)
Date: Tue, 22 Jun 2021 10:11:41 -0700
Subject: [EXTERNAL] A question about memory order on x86_64
In-Reply-To: <4c5316c5-4baa-80a2-656d-ffab7e74ff3a@oracle.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
 <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
 <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>
 <a26d756f-4c69-3e01-95a1-6ae82a85a6b8@amazon.com>
 <4c5316c5-4baa-80a2-656d-ffab7e74ff3a@oracle.com>
Message-ID: <CAHPdc0nD2S9Sn_C725YKQXkBuGsCgfq_tbHJqqDMT0_wNccgUA@mail.gmail.com>

> So they essentially lock out the change while they are writing - which
means when the writing could block indefinitely then the change is also
blocked indefinitely.

Yes,  this kind of synchronization is biased to readers(cheap). updater has
to wait(expensive).
I think it's fair enough, changing log configuration is rare.

> Where is AsyncLogWriter::write participating in this RCU mechanism?

when  logsites enqueue messages to the async buffer, they use RCU counters
as well.

The intention of flush()  is to flush all pending messages, either by
flush() or by async log thread.
_io_sem is a handshake protocol for two stakeholders.  You showed me that
this so-called "protocol" was broken if one thread invokes multiple flush()
in a row.

I changed flush() yesterday.  It just inserts a special token to the buffer
and waits for completion. This guarantees to
serialize multiple flush() calls.  I have run overnight, no problem is
identified.

How about this change?
https://openjdk.github.io/cr/?repo=jdk&pr=4408&range=05#udiff-0-src/hotspot/share/logging/logAsyncWriter.cpp

> I made the change to hold the io_sem for all of write() and the tests
passed in tiers 6 and 7.

What did you change?
P/V operations perform on io_sem(1) once every write(), but I feel it's
difficult to control the scheduler.




On Mon, Jun 21, 2021 at 5:39 PM David Holmes <david.holmes at oracle.com>
wrote:

> On 22/06/2021 9:56 am, Liu, Xin wrote:
> > Hi, David,
> >
> > LogConfiguration::configure_output() is intriguing. That's why I try to
> > explain/comment it in that PR.
> >
> > For sync logging, the RCU reader counter remains > 0 in "writing"
> > period. LogOutputList::Iterator is a RAII class. Its ctor calls
> > increase_readers() and dtor calls decrease_readers().
> >
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logTagSet.cpp#L77
> >
> > When the users decide to disable a LogOutput, they need to adjust levels
> > first. eg. change tagset 'gc' from DEBUG to OFF. There's a RCU
> > synchronization "wait_until_no_readers()" inside of
> > LogOutputList::update_output_level().
> >
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L241
> >
> > When this function returns, it means that all logsites have seen that
> > tagset's level change and all ongoing "writings" have done because
> > _active_readers was once back to zero. There're 200+ tagsets. Each
> > changed tagset needs a RCU synchronization.
> >
> > void LogOutputList::wait_until_no_readers() const {
> >    OrderAccess::storeload();
> >    while (_active_readers != 0) {
> >      // Busy wait
> >    }
> > }
> >
> > Of course, logsites are still active after wait_until_no_readers(), but
> > they have seen new levels for the tagsets. They won't emit logs to the
> > deleting LogOutput. Therefore, it's safe to delete it.
>
> So they essentially lock out the change while they are writing - which
> means when the writing could block indefinitely then the change is also
> blocked indefinitely:
>
> void LogTagSet::log(LogLevelType level, const char* msg) {
>    LogDecorations decorations(level, *this, _decorators);
>    for (LogOutputList::Iterator it = _output_list.iterator(level); it !=
> _output_list.end(); it++) {
>      (*it)->write(decorations, msg);
>    }
> }
>
> > I would like to make async log a natural extension of current lock-free
> > mechanism. The RCU counters only control "enqueuing" periods instead of
> > "writing" periods. As long as flush() works, it's still correct.
>
> Where is AsyncLogWriter::write participating in this RCU mechanism? The
> AsyncLogMessages that were enqueued, and have now been dequeued ready to
> be written, have already captured their "output", but there is nothing
> to protect those outputs. You can't guarantee that the flush() call
> handles all pre-existing enqueued messages, before that thread deletes
> the output. You would have to ensure that the write() from flush() waits
> for the AsyncLogWriter thread to complete any in-progress write() call
> before the flushing write() proceeds. I think you need to hold the
> io_sem across the entire write() to ensure it is executed atomically (we
> just need to make sure that can't lead to any deadlock scenarios with
> the other locking mechanisms in use.
>
> David
>
> > thanks,
> > --lx
> >
> >
> >
> > On 6/21/21 4:28 PM, David Holmes wrote:
> >> But we can't do that as we could block indefinitely while writing.
> >>
> >> Backing up a step lets ignore async logging for a moment. How does
> >> synchronous logging deal with this problem? What ensures that a log
> >> request can't use an output that is being concurrently deleted by a
> >> configuration change?
>

From github.com+42899633+eastig at openjdk.java.net  Tue Jun 22 17:26:25 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 22 Jun 2021 17:26:25 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <Y5u8J-SDfEHueIvGL4xNlZlbpBThsVo7l6HVAsHIr_Q=.5d8aac64-cddc-41cc-a54c-d8e2d81446bd@github.com>

On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 123:

> 121:         if (!wb.isMethodCompiled(cons)) {
> 122:             throw new RuntimeException("Timeout");
> 123:         }

Why not to use `CompilerWhiteBoxTest.waitBackgroundCompilation`:

try {
  CompilerWhiteBoxTest.waitBackgroundCompilation(cons);
} catch (InterruptedException e) {
  throw new RuntimeException("Timeout");
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/4558

From xliu at openjdk.java.net  Tue Jun 22 18:43:51 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 22 Jun 2021 18:43:51 GMT
Subject: [jdk17] RFR: 8269064: Dropped messages of AsyncLogWriter cause memleak
Message-ID: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>

This patch freed c-strs for the dropped messages. Those c-strs are allocated from os::strdup.

-------------

Commit messages:
 - 8269064: Dropped messages of AsyncLogWriter cause memleak

Changes: https://git.openjdk.java.net/jdk17/pull/121/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=121&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269064
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/121.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/121/head:pull/121

PR: https://git.openjdk.java.net/jdk17/pull/121

From xliu at openjdk.java.net  Tue Jun 22 18:50:58 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 22 Jun 2021 18:50:58 GMT
Subject: [jdk17] RFR: 8269064: Dropped messages of AsyncLogWriter cause
 memleak [v2]
In-Reply-To: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>
References: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>
Message-ID: <XjZ3qBBWJVegZRY_SwDkvVSpkTHRXkS_Cew-ZPXVVmA=.4cb1775f-6a77-4c7e-9a1d-e24da9fbc533@github.com>

> This patch freed c-strs for the dropped messages. Those c-strs are allocated from os::strdup.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  os::free can handle nullptr.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/121/files
  - new: https://git.openjdk.java.net/jdk17/pull/121/files/1adeeecd..7885b41b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=121&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=121&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/121.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/121/head:pull/121

PR: https://git.openjdk.java.net/jdk17/pull/121

From coleenp at openjdk.java.net  Tue Jun 22 21:07:04 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 21:07:04 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix INT32_MIN and cache padding.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3980/files
  - new: https://git.openjdk.java.net/jdk/pull/3980/files/7c287908..07138653

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3980&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3980&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3980.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3980/head:pull/3980

PR: https://git.openjdk.java.net/jdk/pull/3980

From dcubed at openjdk.java.net  Tue Jun 22 21:25:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 21:25:26 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
Message-ID: <skhQvqNE-MotIH7raAjFRvlxAOtfiqobJLAuZRaICdE=.dca17f44-4231-45d9-86f1-ee14ea9ae5cc@github.com>

On Tue, 22 Jun 2021 21:07:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix INT32_MIN and cache padding.

Re-reviewed v01 incremental. Thumbs up!

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From lfoltan at openjdk.java.net  Tue Jun 22 21:30:29 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Tue, 22 Jun 2021 21:30:29 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v5]
In-Reply-To: <y8jrWW1Cs-3hoBv61y23THQ_7OzAAAKwWRgSNpxALfY=.3dee752e-8e4e-4f24-ac2a-60c9f4f3ea3b@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <y8jrWW1Cs-3hoBv61y23THQ_7OzAAAKwWRgSNpxALfY=.3dee752e-8e4e-4f24-ac2a-60c9f4f3ea3b@github.com>
Message-ID: <CklpdW5ojduOBmVRnJY-UrD0ldHd0kf6oaEcCFzw72s=.6b707111-c169-4122-bdcb-9a6fe59bf7c5@github.com>

On Tue, 22 Jun 2021 12:34:22 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
>> 
>> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
>> 
>> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
>> 
>> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove senseless comment

Looks good!
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4497

From david.holmes at oracle.com  Tue Jun 22 22:59:21 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Jun 2021 08:59:21 +1000
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <eXXwjQ_4SG4jRQv36t3S3qgppcet32azVU7o6dZ4TV8=.58cfbf7d-4b41-4f05-8a7b-f4fc9c926180@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
 <eXXwjQ_4SG4jRQv36t3S3qgppcet32azVU7o6dZ4TV8=.58cfbf7d-4b41-4f05-8a7b-f4fc9c926180@github.com>
Message-ID: <804dea9b-af9b-0ef0-7305-3421ba27ab16@oracle.com>

On 23/06/2021 12:39 am, Coleen Phillimore wrote:
> On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
>> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
>>
>> Tested with tier1-6.
> 
> I am looking at all the threads we create in the vm like the ServiceThread (look for Threads::add()), but not attach_current_thread in jni.  You're right, we have to make this thread safepoint here.
> I wonder why some threads we create call ThreadGroup.add and some don't.  There's lots of duplicate code that's slightly different for each.

I'm not sure on the "why". Some internal threads (e.g. AttachListener) 
don't call the j.l.Thread constructor and so have to directly call the 
ThreadGroup.add method. I suspect because these are not true Java 
threads that there is some Java-side logic that Thread construction 
performs which is not suitable for these internal threads.

> Unfortunately now I need a fix for JDK-8215948, hopefully without another duplicate copy of this thread creation code so I can write my handshake test.

Okay guess I'd better look at it again then. :) I can determine which 
variant of the j.l.Thread creation logic is suitable and then factor 
that out into a support method like Thread::create_internal_java_thread().

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4512
> 

From dholmes at openjdk.java.net  Tue Jun 22 23:18:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 23:18:30 GMT
Subject: [jdk17] RFR: 8269064: Dropped messages of AsyncLogWriter cause
 memleak [v2]
In-Reply-To: <XjZ3qBBWJVegZRY_SwDkvVSpkTHRXkS_Cew-ZPXVVmA=.4cb1775f-6a77-4c7e-9a1d-e24da9fbc533@github.com>
References: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>
 <XjZ3qBBWJVegZRY_SwDkvVSpkTHRXkS_Cew-ZPXVVmA=.4cb1775f-6a77-4c7e-9a1d-e24da9fbc533@github.com>
Message-ID: <opIE2FIZwKETPPW9KPVF1Nh4N6fMqRQJpqAZoWaJ7bE=.bc554979-f262-4d14-b817-7ccd80e59d97@github.com>

On Tue, 22 Jun 2021 18:50:58 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch freed c-strs for the dropped messages. Those c-strs are allocated from os::strdup.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   os::free can handle nullptr.

Hi Xin,

This fix looks good and trivial.

Thanks for splitting the two issues.

David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/121

From david.holmes at oracle.com  Tue Jun 22 23:41:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Jun 2021 09:41:07 +1000
Subject: [EXTERNAL] A question about memory order on x86_64
In-Reply-To: <CAHPdc0nD2S9Sn_C725YKQXkBuGsCgfq_tbHJqqDMT0_wNccgUA@mail.gmail.com>
References: <1e8fd577-d041-db44-b749-fb12a92d1c27@amazon.com>
 <d4999854-ffe7-93fa-e456-9deb80fc2290@oracle.com>
 <CAHPdc0krrF6sNOVrE0MhRGMUuz1B2-qSRCHJwvPqyfSwjYvgyA@mail.gmail.com>
 <fc406054-7bf2-8bc4-cd8c-4fb505796d67@oracle.com>
 <d2e05d24-b1ad-294b-012c-806c5338d997@oracle.com>
 <a26d756f-4c69-3e01-95a1-6ae82a85a6b8@amazon.com>
 <4c5316c5-4baa-80a2-656d-ffab7e74ff3a@oracle.com>
 <CAHPdc0nD2S9Sn_C725YKQXkBuGsCgfq_tbHJqqDMT0_wNccgUA@mail.gmail.com>
Message-ID: <b6e6b0b7-e39f-fffe-3b87-e80bef9928f6@oracle.com>

On 23/06/2021 3:11 am, Liu Xin wrote:
>  > So they essentially lock out the change while they are writing - which
> means when the writing could block indefinitely then the change is also
> blocked indefinitely.
> 
> Yes,? this kind of synchronization is biased to readers(cheap). updater 
> has to wait(expensive).
> I think it's fair enough, changing log configuration is rare.
> 
>  > Where is AsyncLogWriter::write participating in this RCU mechanism?
> 
> when? logsites enqueue messages to the async buffer, they use RCU 
> counters as well.
> 
> The intention of flush()? is to flush all pending messages, either by 
> flush() or by async log thread.
> _io_sem is a handshake protocol for two stakeholders.? You showed me 
> that this so-called "protocol" was broken if one thread invokes multiple 
> flush() in a row.
> 
> I changed flush() yesterday.? It just inserts a special token to the 
> buffer and waits for completion. This guarantees to
> serialize multiple flush() calls.? I have run overnight, no problem is 
> identified.
> 
> How about this change?
> https://openjdk.github.io/cr/?repo=jdk&pr=4408&range=05#udiff-0-src/hotspot/share/logging/logAsyncWriter.cpp 
> <https://openjdk.github.io/cr/?repo=jdk&pr=4408&range=05#udiff-0-src/hotspot/share/logging/logAsyncWriter.cpp>
> 
>  > I made the change to hold the io_sem for all of write() and the tests
> passed in tiers 6 and 7.
> 
> What did you change?

I did io_sem.wait at the start of write(), so that it is executed 
atomically, to completion.

David
-----

> P/V operations perform on io_sem(1) once every write(), but I feel it's 
> difficult to control the scheduler.
> 
> 
> 
> 
> On Mon, Jun 21, 2021 at 5:39 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 22/06/2021 9:56 am, Liu, Xin wrote:
>      > Hi, David,
>      >
>      > LogConfiguration::configure_output() is intriguing. That's why I
>     try to
>      > explain/comment it in that PR.
>      >
>      > For sync logging, the RCU reader counter remains > 0 in "writing"
>      > period. LogOutputList::Iterator is a RAII class. Its ctor calls
>      > increase_readers() and dtor calls decrease_readers().
>      >
>     https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logTagSet.cpp#L77
>     <https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logTagSet.cpp#L77>
>      >
>      > When the users decide to disable a LogOutput, they need to adjust
>     levels
>      > first. eg. change tagset 'gc' from DEBUG to OFF. There's a RCU
>      > synchronization "wait_until_no_readers()" inside of
>      > LogOutputList::update_output_level().
>      >
>     https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L241
>     <https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L241>
>      >
>      > When this function returns, it means that all logsites have seen that
>      > tagset's level change and all ongoing "writings" have done because
>      > _active_readers was once back to zero. There're 200+ tagsets. Each
>      > changed tagset needs a RCU synchronization.
>      >
>      > void LogOutputList::wait_until_no_readers() const {
>      >? ? OrderAccess::storeload();
>      >? ? while (_active_readers != 0) {
>      >? ? ? // Busy wait
>      >? ? }
>      > }
>      >
>      > Of course, logsites are still active after
>     wait_until_no_readers(), but
>      > they have seen new levels for the tagsets. They won't emit logs
>     to the
>      > deleting LogOutput. Therefore, it's safe to delete it.
> 
>     So they essentially lock out the change while they are writing - which
>     means when the writing could block indefinitely then the change is also
>     blocked indefinitely:
> 
>     void LogTagSet::log(LogLevelType level, const char* msg) {
>      ? ?LogDecorations decorations(level, *this, _decorators);
>      ? ?for (LogOutputList::Iterator it = _output_list.iterator(level);
>     it !=
>     _output_list.end(); it++) {
>      ? ? ?(*it)->write(decorations, msg);
>      ? ?}
>     }
> 
>      > I would like to make async log a natural extension of current
>     lock-free
>      > mechanism. The RCU counters only control "enqueuing" periods
>     instead of
>      > "writing" periods. As long as flush() works, it's still correct.
> 
>     Where is AsyncLogWriter::write participating in this RCU mechanism? The
>     AsyncLogMessages that were enqueued, and have now been dequeued
>     ready to
>     be written, have already captured their "output", but there is nothing
>     to protect those outputs. You can't guarantee that the flush() call
>     handles all pre-existing enqueued messages, before that thread deletes
>     the output. You would have to ensure that the write() from flush()
>     waits
>     for the AsyncLogWriter thread to complete any in-progress write() call
>     before the flushing write() proceeds. I think you need to hold the
>     io_sem across the entire write() to ensure it is executed atomically
>     (we
>     just need to make sure that can't lead to any deadlock scenarios with
>     the other locking mechanisms in use.
> 
>     David
> 
>      > thanks,
>      > --lx
>      >
>      >
>      >
>      > On 6/21/21 4:28 PM, David Holmes wrote:
>      >> But we can't do that as we could block indefinitely while writing.
>      >>
>      >> Backing up a step lets ignore async logging for a moment. How does
>      >> synchronous logging deal with this problem? What ensures that a log
>      >> request can't use an output that is being concurrently deleted by a
>      >> configuration change?
> 

From dholmes at openjdk.java.net  Tue Jun 22 23:53:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 23:53:27 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
Message-ID: <p2LwhNhbrfHu1eTgbp1qsFCveY0iF_NSmDcgD82azP0=.94baa733-6b8e-4156-bd3f-f16fd22d4a8f@github.com>

On Tue, 22 Jun 2021 21:07:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix INT32_MIN and cache padding.

Looks good!

Good catch on the padding @dcubed-ojdk !

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleen.phillimore at oracle.com  Wed Jun 23 00:38:03 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 22 Jun 2021 20:38:03 -0400
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <804dea9b-af9b-0ef0-7305-3421ba27ab16@oracle.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
 <eXXwjQ_4SG4jRQv36t3S3qgppcet32azVU7o6dZ4TV8=.58cfbf7d-4b41-4f05-8a7b-f4fc9c926180@github.com>
 <804dea9b-af9b-0ef0-7305-3421ba27ab16@oracle.com>
Message-ID: <902f36a9-4099-d8f9-f02e-e2232405a863@oracle.com>



On 6/22/21 6:59 PM, David Holmes wrote:
> On 23/06/2021 12:39 am, Coleen Phillimore wrote:
>> On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore 
>> <coleenp at openjdk.org> wrote:
>>
>>> The handshake code tests if the JavaThread->is_exiting or that the 
>>> threadObj() is null. Ever since JDK-8244997, once the JavaThread is 
>>> running, the _threadObj won't be null until JavaThread is destroyed. 
>>> So testing is_exiting is all you need to do.
>>> In gtest, the test JavaThread doesn't create a _threadObj 
>>> JDK-8215948 so removing this unnecessary test allows writing gtests 
>>> for handshakes.
>>>
>>> Tested with tier1-6.
>>
>> I am looking at all the threads we create in the vm like the 
>> ServiceThread (look for Threads::add()), but not 
>> attach_current_thread in jni.? You're right, we have to make this 
>> thread safepoint here.
>> I wonder why some threads we create call ThreadGroup.add and some 
>> don't.? There's lots of duplicate code that's slightly different for 
>> each.
>
> I'm not sure on the "why". Some internal threads (e.g. AttachListener) 
> don't call the j.l.Thread constructor and so have to directly call the 
> ThreadGroup.add method. I suspect because these are not true Java 
> threads that there is some Java-side logic that Thread construction 
> performs which is not suitable for these internal threads.

Seems that ServiceTherad, MonitorDeflationThread and JFRRecorderThread 
do not call ThreadGroup.add, but NotificationThread, SignalThread (for 
-xrs), AttachListener, JNI attached threads, don't know JvmtiAgent 
threads, and JVM_StartThread (calls JavaThread::prepare).

There's lots of variations with similar code to create threads.
>
>> Unfortunately now I need a fix for JDK-8215948, hopefully without 
>> another duplicate copy of this thread creation code so I can write my 
>> handshake test.
>
> Okay guess I'd better look at it again then. :) I can determine which 
> variant of the j.l.Thread creation logic is suitable and then factor 
> that out into a support method like 
> Thread::create_internal_java_thread().

Please!? Refactoring would be very nice!

Thanks,
Coleen

>
> David
> -----
>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4512
>>


From github.com+20216587+miao-zheng at openjdk.java.net  Wed Jun 23 03:01:40 2021
From: github.com+20216587+miao-zheng at openjdk.java.net (Miao Zheng)
Date: Wed, 23 Jun 2021 03:01:40 GMT
Subject: RFR: JDK-8269206 A small typo in comment in
 test/lib/sun/hotspot/WhiteBox.java
Message-ID: <5itCnHEi-0Yn_SKd9AO7jPS8UEY5cUTb58FW6EkyVqU=.8db5adde-1a38-4205-b8ac-7c78d7695420@github.com>

return getMethodCompilationLevel(method, false /*not ost*/); 

"ost" should be "osr"

-------------

Commit messages:
 - A small typo in comment in test/lib/sun/hotspot/WhiteBox.java

Changes: https://git.openjdk.java.net/jdk/pull/4566/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4566&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269206
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4566.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4566/head:pull/4566

PR: https://git.openjdk.java.net/jdk/pull/4566

From minqi at openjdk.java.net  Wed Jun 23 06:19:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 06:19:56 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp
Message-ID: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>

Hi, Please review
systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.

Tests: tier1,tier3,tier4

Thanks
Yumin

-------------

Commit messages:
 - 8268821: Split systemDictionaryShared.cpp

Changes: https://git.openjdk.java.net/jdk/pull/4568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268821
  Stats: 2606 lines in 11 files changed: 1310 ins; 1101 del; 195 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4568/head:pull/4568

PR: https://git.openjdk.java.net/jdk/pull/4568

From david.holmes at oracle.com  Wed Jun 23 06:45:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Jun 2021 16:45:03 +1000
Subject: RFR: 8268821: Split systemDictionaryShared.cpp
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <0bef77d1-94fd-85fa-65a3-60d52701c4df@oracle.com>

Hi Yumin,

On 23/06/2021 4:19 pm, Yumin Qi wrote:
> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.

I'm not really seeing a consistent or recognisable naming pattern here. 
We seem to have a mix of:

- cds/foo.cpp
- cds/fooShared.cpp
- cds/sharedFoo.cpp

Can we establish a simple naming scheme here?

Thanks,
David

> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin
> 
> -------------
> 
> Commit messages:
>   - 8268821: Split systemDictionaryShared.cpp
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4568/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8268821
>    Stats: 2606 lines in 11 files changed: 1310 ins; 1101 del; 195 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4568.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4568/head:pull/4568
> 
> PR: https://git.openjdk.java.net/jdk/pull/4568
> 

From dholmes at openjdk.java.net  Wed Jun 23 06:54:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Jun 2021 06:54:28 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <ieTmQ_ilKhT7hfwmB98IvZA3zJDWIOwAIoYVCAbhmW4=.ebf011fc-a8d4-4409-b9f9-fb726ef3938f@github.com>

On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

Hi Christoph,

I think, given the failure scenario the test is trying to test, that the best, and simplest, fix is to update the:

* @requires vm.compMode=="Xmixed" &
*           (vm.opt.TieredStopAtLevel == null | vm.opt.TieredStopAtLevel == 4)
 
so that it requires C2 to be present and so is skipped on a client-only VM.

Thanks,
David

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4558

From dholmes at openjdk.java.net  Wed Jun 23 07:22:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Jun 2021 07:22:26 GMT
Subject: RFR: JDK-8269206 A small typo in comment in
 test/lib/sun/hotspot/WhiteBox.java
In-Reply-To: <5itCnHEi-0Yn_SKd9AO7jPS8UEY5cUTb58FW6EkyVqU=.8db5adde-1a38-4205-b8ac-7c78d7695420@github.com>
References: <5itCnHEi-0Yn_SKd9AO7jPS8UEY5cUTb58FW6EkyVqU=.8db5adde-1a38-4205-b8ac-7c78d7695420@github.com>
Message-ID: <dG3QJyMWLUEUFD-z-LE_ltI9QVS2rKwvZ5gMmNp1GxI=.68e7f4f3-8ba7-4bd0-a5c9-3711a761044e@github.com>

On Wed, 23 Jun 2021 02:53:24 GMT, Miao Zheng <github.com+20216587+miao-zheng at openjdk.org> wrote:

> return getMethodCompilationLevel(method, false /*not ost*/); 
> 
> "ost" should be "osr"

Hi,

This is fine and trivial (ie only needs one reviewer and can be integrated immediately).

Normally such trivial matters are fixed when doing something else in that file - otherwise the overhead of performing the fix (JBS issue, PR, reviews) is just too much to be practical. In fact I recall seeing this typo (or a very similar one) fixed in a recent PR I was reviewing.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4566

From david.holmes at oracle.com  Wed Jun 23 07:36:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Jun 2021 17:36:07 +1000
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v6]
In-Reply-To: <houOltaq5lrYR4NyfVvomVstB9N6Z5ddCEP87RPQds8=.8ad1a37a-c504-477f-b66b-827ed51a2de1@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <houOltaq5lrYR4NyfVvomVstB9N6Z5ddCEP87RPQds8=.8ad1a37a-c504-477f-b66b-827ed51a2de1@github.com>
Message-ID: <43b61824-04c2-5ecf-0c18-3693711597de@oracle.com>

Hi Xin,

On 23/06/2021 2:50 am, Xin Liu wrote:
>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
> 
> Xin Liu 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 ten additional commits since the last revision:
> 
>   - AsyncLogWrite::flush() uses a synchronization token and wait for completion.
>     
>     This patch serializes all flush() calls in one thread.

I put this through our test system and tiers 6 and 7 also passed this way.

So to walk through the fix ...

When changing the configuration:
- first update the values so that future log entries will use the new 
ones (this includes the RCU check for "no readers")
- insert a token item into the enqueued messages for the AsyncLog thread 
to see
- wait on the flush_sem

In this way when the asyncLog thread finds the token it can signal the 
thread blocked in the flush() call and that thread can then proceed to 
change the configuration knowing no enqueued messages can be dependent 
on anything being changed.

I think that seem okay. Only ever doing the writing in the asyncLog 
thread seems cleaner too.

The only thing I need to double-check is whether there is any potential 
termination race.

In the meantime, I would suggest closing this PR and opening a new one 
for JDK 17 as we need to get this fixed there ASAP. And a fresh PR will 
make things a lot clearer for other reviewers.

Thanks,
David

>   - Merge branch 'master' into JDK-8267952
>   - Revert "Use Atomic::load/store for decorators."
>     
>     This reverts commit f279f2639bc638a35ae6c716987feb22d36a2a07.
>   - Revert "Fix VC++ warning C4099"
>     
>     This reverts commit 157a065876850df784d9e7c034e106f4532b607a.
>   - Fix VC++ warning C4099
>   - Use Atomic::load/store for decorators.
>     
>     This patch also installed a sanity check which will assert that
>     LogOutput::_decorators is subset of LogDecocrations. It will disclose
>     more information if the assertion fails.
>   - Merge branch 'master' into JDK-8267952
>   - Add comments in LogTagSet::log().
>   - 8267952: async logging supports to dynamically change tags and decorators
> 
> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/4408/files
>    - new: https://git.openjdk.java.net/jdk/pull/4408/files/157a0658..ae3ae36d
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=05
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4408&range=04-05
> 
>    Stats: 18757 lines in 334 files changed: 11361 ins; 6472 del; 924 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4408.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4408/head:pull/4408
> 
> PR: https://git.openjdk.java.net/jdk/pull/4408
> 

From jiefu at openjdk.java.net  Wed Jun 23 08:02:30 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Jun 2021 08:02:30 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
Message-ID: <PSVtMnvltsELInuHE5EXxYuuMjCvmEWBTOHWCExrqqs=.2bc928d4-df66-47af-a27c-b6424c397495@github.com>

On Sun, 20 Jun 2021 09:52:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch which:
>  1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
>  2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`
> 
> Testing:
>   - Linux/x64, MacOS/x64
> 
> Thanks.
> Best regards,
> Jie

@iignatev , the test had been restored and fixed with `-XX:MaxRAMPercentage=25`.
Are you OK with this change?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/104

From simonis at openjdk.java.net  Wed Jun 23 08:08:26 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 23 Jun 2021 08:08:26 GMT
Subject: [jdk17] RFR: 8269064: Dropped messages of AsyncLogWriter cause
 memleak [v2]
In-Reply-To: <XjZ3qBBWJVegZRY_SwDkvVSpkTHRXkS_Cew-ZPXVVmA=.4cb1775f-6a77-4c7e-9a1d-e24da9fbc533@github.com>
References: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>
 <XjZ3qBBWJVegZRY_SwDkvVSpkTHRXkS_Cew-ZPXVVmA=.4cb1775f-6a77-4c7e-9a1d-e24da9fbc533@github.com>
Message-ID: <FyAFqxRZedeQxH_l-ohcnTGoFZko5kN3WaAEUnGuJdE=.8546ac84-c34e-4193-8bd8-34ce83babf97@github.com>

On Tue, 22 Jun 2021 18:50:58 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch freed c-strs for the dropped messages. Those c-strs are allocated from os::strdup.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   os::free can handle nullptr.

Looks good to me.

Thanks for fixing,
Volker

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/121

From github.com+20216587+miao-zheng at openjdk.java.net  Wed Jun 23 08:48:25 2021
From: github.com+20216587+miao-zheng at openjdk.java.net (Miao Zheng)
Date: Wed, 23 Jun 2021 08:48:25 GMT
Subject: RFR: JDK-8269206 A small typo in comment in
 test/lib/sun/hotspot/WhiteBox.java
In-Reply-To: <dG3QJyMWLUEUFD-z-LE_ltI9QVS2rKwvZ5gMmNp1GxI=.68e7f4f3-8ba7-4bd0-a5c9-3711a761044e@github.com>
References: <5itCnHEi-0Yn_SKd9AO7jPS8UEY5cUTb58FW6EkyVqU=.8db5adde-1a38-4205-b8ac-7c78d7695420@github.com>
 <dG3QJyMWLUEUFD-z-LE_ltI9QVS2rKwvZ5gMmNp1GxI=.68e7f4f3-8ba7-4bd0-a5c9-3711a761044e@github.com>
Message-ID: <ADWc-dl3aWq_rOJXKpUkqH4K4TwiRa7T277qafo7GPU=.82aa90b1-3806-4239-8c89-daf9c72023fc@github.com>

On Wed, 23 Jun 2021 07:19:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> return getMethodCompilationLevel(method, false /*not ost*/); 
>> 
>> "ost" should be "osr"
>
> Hi,
> 
> This is fine and trivial (ie only needs one reviewer and can be integrated immediately).
> 
> Normally such trivial matters are fixed when doing something else in that file - otherwise the overhead of performing the fix (JBS issue, PR, reviews) is just too much to be practical. In fact I recall seeing this typo (or a very similar one) fixed in a recent PR I was reviewing.
> 
> Thanks,
> David

@dholmes-ora Thanks for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4566

From xliu at openjdk.java.net  Wed Jun 23 08:48:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Jun 2021 08:48:37 GMT
Subject: RFR: 8267952: async logging supports to dynamically change tags
 and decorators [v6]
In-Reply-To: <houOltaq5lrYR4NyfVvomVstB9N6Z5ddCEP87RPQds8=.8ad1a37a-c504-477f-b66b-827ed51a2de1@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
 <houOltaq5lrYR4NyfVvomVstB9N6Z5ddCEP87RPQds8=.8ad1a37a-c504-477f-b66b-827ed51a2de1@github.com>
Message-ID: <gPmxA1sqg-tubsS0QgEuGezKMqqQdjEpMwDw08MRxUI=.acc5275d-38d8-4b11-9994-b046a251ad6d@github.com>

On Tue, 22 Jun 2021 16:50:16 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> Xin Liu 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 ten additional commits since the last revision:
> 
>  - AsyncLogWrite::flush() uses a synchronization token and wait for completion.
>    
>    This patch serializes all flush() calls in one thread.
>  - Merge branch 'master' into JDK-8267952
>  - Revert "Use Atomic::load/store for decorators."
>    
>    This reverts commit f279f2639bc638a35ae6c716987feb22d36a2a07.
>  - Revert "Fix VC++ warning C4099"
>    
>    This reverts commit 157a065876850df784d9e7c034e106f4532b607a.
>  - Fix VC++ warning C4099
>  - Use Atomic::load/store for decorators.
>    
>    This patch also installed a sanity check which will assert that
>    LogOutput::_decorators is subset of LogDecocrations. It will disclose
>    more information if the assertion fails.
>  - Merge branch 'master' into JDK-8267952
>  - Add comments in LogTagSet::log().
>  - 8267952: async logging supports to dynamically change tags and decorators

I understand your fix. You mark write() with keyword "synchonized in java" . One bonus is flush() is MT-safe as well.

Yes, the benefit of token is that only one thread calls write().  It doesn't pay "synchronized" method cost if no flush() is invoked. I will pick one solution and remake the PR. thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Wed Jun 23 08:48:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Jun 2021 08:48:37 GMT
Subject: Withdrawn: 8267952: async logging supports to dynamically change tags
 and decorators
In-Reply-To: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
References: <FywURE9AXOtH3QDc4Z-32bfk_x_2sJ0ZIEsnD4Yn8bM=.ab6e733c-e882-4619-a5da-e19e6e27f7ea@github.com>
Message-ID: <unVmlKGJZa-4wjWI7DWYMdome_qvQ1IfpXne24J4PCA=.e6c543c8-859e-4951-b8a7-063d20528959@github.com>

On Tue, 8 Jun 2021 03:10:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Support dynamic reconfiguration for async logging. 2 unittests are provided.
> The regression test discovers a race condition in LogTagSet::log() even with
> synchronous logging. It's not MT-safe if context switch happens between the
> creation of LogDecorations  and LogOutputList::Iterator. fixed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4408

From xliu at openjdk.java.net  Wed Jun 23 08:49:29 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Jun 2021 08:49:29 GMT
Subject: [jdk17] Integrated: 8269064: Dropped messages of AsyncLogWriter cause
 memleak
In-Reply-To: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>
References: <pE-5fQ2Mdw74r229PRMVa2bj4ahvSCzG9VA6BfGmGJ0=.fef76013-0f0d-4dee-9a9d-d8659ab2c795@github.com>
Message-ID: <aI74-CPpur_MVQG2h3zrUjAtJAxMefXr_WUKzCGI01Q=.de08ce97-60d0-4feb-ab64-777c06554d78@github.com>

On Tue, 22 Jun 2021 18:37:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch freed c-strs for the dropped messages. Those c-strs are allocated from os::strdup.

This pull request has now been integrated.

Changeset: 1323be54
Author:    Xin Liu <xliu at openjdk.org>
Committer: Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/1323be54d26833d261ef5b53ae0ee9b58a96aabb
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8269064: Dropped messages of AsyncLogWriter cause memleak

Reviewed-by: dholmes, simonis

-------------

PR: https://git.openjdk.java.net/jdk17/pull/121

From github.com+20216587+miao-zheng at openjdk.java.net  Wed Jun 23 08:55:30 2021
From: github.com+20216587+miao-zheng at openjdk.java.net (Miao Zheng)
Date: Wed, 23 Jun 2021 08:55:30 GMT
Subject: Integrated: JDK-8269206 A small typo in comment in
 test/lib/sun/hotspot/WhiteBox.java
In-Reply-To: <5itCnHEi-0Yn_SKd9AO7jPS8UEY5cUTb58FW6EkyVqU=.8db5adde-1a38-4205-b8ac-7c78d7695420@github.com>
References: <5itCnHEi-0Yn_SKd9AO7jPS8UEY5cUTb58FW6EkyVqU=.8db5adde-1a38-4205-b8ac-7c78d7695420@github.com>
Message-ID: <Ao3FcjDlKHhv7m6h3-FliNKY_9B0KdcAu3PGZWpOssY=.f2b18d65-5c9e-4e07-9bc7-7ec66437dee4@github.com>

On Wed, 23 Jun 2021 02:53:24 GMT, Miao Zheng <github.com+20216587+miao-zheng at openjdk.org> wrote:

> return getMethodCompilationLevel(method, false /*not ost*/); 
> 
> "ost" should be "osr"

This pull request has now been integrated.

Changeset: 2c29d790
Author:    miao zheng <emoryzheng at tencent.com>
Committer: Hui Shi <hshi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c29d790cac0525130ade6caf10a60ba5a1320a9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269206: A small typo in comment in test/lib/sun/hotspot/WhiteBox.java

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4566

From cgo at openjdk.java.net  Wed Jun 23 10:44:53 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 23 Jun 2021 10:44:53 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM [v2]
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com>

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:

  Adds requires compiler2 & revert compilation level detection.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4558/files
  - new: https://git.openjdk.java.net/jdk/pull/4558/files/b1a40f61..2aabea99

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4558&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4558&range=00-01

  Stats: 10 lines in 1 file changed: 1 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4558/head:pull/4558

PR: https://git.openjdk.java.net/jdk/pull/4558

From cgo at openjdk.java.net  Wed Jun 23 10:44:53 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 23 Jun 2021 10:44:53 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM
In-Reply-To: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
Message-ID: <OnNIViEAvcdOyRxI3R3xqw1JVlhoxs-0mM16O0zCM4M=.716b7f4a-cdc3-4e6c-aeee-ab8ad756af77@github.com>

On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
> 
> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
> 
> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).

Thanks for your reviews.

I initially didn't want to limit the test case to tiered VMs, since the bug said "C1", but if that's OK I am fine with it as well. I also picked up one of the suggestion @eastig gave me, which is check the return value of `enqueueMethodForCompilation` since I think this is a reasonable addition and makes the test more robust.

I am not using `CompilerWhiteBoxTest.waitBackgroundCompilation`, since it had some issues with the enabled security manager and I didn't want to complicate the test case more. I think with the new `@requires` and the check of the return value from `enqueueMethodForCompilation`, we should be save here and the loop should always terminate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4558

From hseigel at openjdk.java.net  Wed Jun 23 12:15:35 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 23 Jun 2021 12:15:35 GMT
Subject: RFR: 8268720: Unspecified checks on NameAndType constants should
 not be performed [v5]
In-Reply-To: <y8jrWW1Cs-3hoBv61y23THQ_7OzAAAKwWRgSNpxALfY=.3dee752e-8e4e-4f24-ac2a-60c9f4f3ea3b@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
 <y8jrWW1Cs-3hoBv61y23THQ_7OzAAAKwWRgSNpxALfY=.3dee752e-8e4e-4f24-ac2a-60c9f4f3ea3b@github.com>
Message-ID: <bBh9f4XeNcg1ICbBq14QlbrDXaVOZgZMQpaRsesffGI=.5f069e12-9bed-445c-8d64-490c71485b27@github.com>

On Tue, 22 Jun 2021 12:34:22 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
>> 
>> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
>> 
>> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
>> 
>> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove senseless comment

Thanks David and Lois for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From hseigel at openjdk.java.net  Wed Jun 23 12:15:38 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 23 Jun 2021 12:15:38 GMT
Subject: Integrated: 8268720: Unspecified checks on NameAndType constants
 should not be performed
In-Reply-To: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
References: <gNJ7ElOure3x1XZ7b-IJMDTdzFlnpQoF_-j2mc5dXaE=.c6d0afb3-aa66-41aa-86bf-6ba835cacfd3@github.com>
Message-ID: <JGrTKE3lAaNZZEtarczsrBJjM3JbH7CYiC_WpXGWmXw=.60a06bfa-b15d-4a8f-bc4a-753d79ac258a@github.com>

On Tue, 15 Jun 2021 20:17:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8268720.  The fix changes the JVM to no longer throw a ClassFormatError exception for a constant pool NameAndType that has a name and descriptor that are both valid, but are incompatible together, such as "<init>()D".
> 
> Note that if the CONSTANT_NameAndType_info for a CONSTANT_Methodref_info contained the name "<init>"and descriptor such as "()D" then a ClassFormatError exception would get thrown because the CONSTANT_Methodref_info would be invalid. JVM Spec section 4.4.2 says:
> 
> If the name of the method in a CONSTANT_Methodref_info structure begins with a '<' ('\u003c'), then the name must be the special name <init>, representing an instance initialization method (?2.9.1). The return type of such a method must be void.
> 
> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and JCK Lang and VM tests on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: f2e690e0
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2e690e0ee503794cb50740170912697640d70ff
Stats:     478 lines in 4 files changed: 447 ins; 15 del; 16 mod

8268720: Unspecified checks on NameAndType constants should not be performed

Reviewed-by: dholmes, lfoltan

-------------

PR: https://git.openjdk.java.net/jdk/pull/4497

From erikj at openjdk.java.net  Wed Jun 23 12:43:27 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 23 Jun 2021 12:43:27 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <hOSi_AH9jXfKt1WUwy1WkhEoll8BW3zij46ChaGqH70=.e6472662-a2c2-4cc8-a5d6-2fdcc1e4ccac@github.com>

On Wed, 23 Jun 2021 06:08:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin

Build changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4568

From dholmes at openjdk.java.net  Wed Jun 23 12:59:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Jun 2021 12:59:49 GMT
Subject: RFR: 8268855: Cleanup name handling in the Thread class and subclasses
Message-ID: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>

Please review this small cleanup item.

We can simplify and cleanup up name() management:

- make name() return "const char *" and only cast away constness at API boundaries when essential
- add type_name() so that we can avoid code like "if (t->is_VM_Thread()) print("VMThread");
- Rename JavaThread::get_thread_name() to name() (no need for the extra indirection)

There are a couple of minor changes to the appearance of some internal threads in the hs_err log e.g.

  0x000055af03e5b1b0 WatcherThread [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]

is now:

  0x000055af03e5b1b0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]

but this shouldn't affect anything and makes things more consistent.

Notes: 

1. While "override" is the ideal style when declaring overriding methods it has to be applied to all virtual methods in a class. So unless "override" is already used in a class, I did not start using it. I have filed a separate RFE to convert the Thread classes to use "override" consistently.
2.  While there is no need to redeclare a virtual method as "virtual" I kept to the existing style in those classes where changes were made.
3. I did not override type_name() for all the JavaThread subclasses as it seemed unnecessary, but happy to hear other views on this.

Testing (in progress):
 - All builds in tiers 1-5
 - GHA
 - tiers 1-3 as a sanity test

Thanks,
David

-------------

Commit messages:
 - Missed ShenandoahControlThread
 - 8268855: Cleanup name handling in the Thread class and subclasses

Changes: https://git.openjdk.java.net/jdk/pull/4569/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4569&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268855
  Stats: 85 lines in 16 files changed: 34 ins; 14 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4569/head:pull/4569

PR: https://git.openjdk.java.net/jdk/pull/4569

From lfoltan at openjdk.java.net  Wed Jun 23 14:15:27 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Wed, 23 Jun 2021 14:15:27 GMT
Subject: RFR: 8268855: Cleanup name handling in the Thread class and
 subclasses
In-Reply-To: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
References: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
Message-ID: <mtnQh7rqqpnYVqkXly-RXlRNxzuvb17ySeKAu-7kn9w=.2a052e63-51d0-427f-ace1-bd759a8d36a6@github.com>

On Wed, 23 Jun 2021 06:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small cleanup item.
> 
> We can simplify and cleanup up name() management:
> 
> - make name() return "const char *" and only cast away constness at API boundaries when essential
> - add type_name() so that we can avoid code like "if (t->is_VM_Thread()) print("VMThread");
> - Rename JavaThread::get_thread_name() to name() (no need for the extra indirection)
> 
> There are a couple of minor changes to the appearance of some internal threads in the hs_err log e.g.
> 
>   0x000055af03e5b1b0 WatcherThread [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> is now:
> 
>   0x000055af03e5b1b0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> but this shouldn't affect anything and makes things more consistent.
> 
> Notes: 
> 
> 1. While "override" is the ideal style when declaring overriding methods it has to be applied to all virtual methods in a class. So unless "override" is already used in a class, I did not start using it. I have filed a separate RFE to convert the Thread classes to use "override" consistently.
> 2.  While there is no need to redeclare a virtual method as "virtual" I kept to the existing style in those classes where changes were made.
> 3. I did not override type_name() for all the JavaThread subclasses as it seemed unnecessary, but happy to hear other views on this.
> 
> Testing (in progress):
>  - All builds in tiers 1-5
>  - GHA
>  - tiers 1-3 as a sanity test
> 
> Thanks,
> David

Looks good!
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4569

From coleenp at openjdk.java.net  Wed Jun 23 14:30:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 14:30:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
Message-ID: <pQCOTRq1qqv1EB-RZjIgTLnbGCHYy_kKu0iC8s7AKug=.a6ec6f54-dffa-434a-be9d-3d2a16fc27ce@github.com>

On Tue, 22 Jun 2021 21:07:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix INT32_MIN and cache padding.

Thank you David, Dan and Thomas.  There are a few other jlongs hanging around in that file, but that's for another day.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Wed Jun 23 14:30:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 14:30:33 GMT
Subject: Integrated: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <FORz0i1lFFXwraT4fLaCT1H2ljlMI-4y1BPJfq531Js=.a7ea8d35-ae8b-4dab-bf0d-f24cd446666e@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

This pull request has now been integrated.

Changeset: f3ba2690
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f3ba2690c5b34673ebf6836c87e45477e1ff91c3
Stats:     28 lines in 5 files changed: 1 ins; 0 del; 27 mod

8256306: ObjectMonitor::_contentions field should not be 'jint'

Reviewed-by: dholmes, stuefe, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From minqi at openjdk.java.net  Wed Jun 23 16:17:29 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 16:17:29 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp
In-Reply-To: <hOSi_AH9jXfKt1WUwy1WkhEoll8BW3zij46ChaGqH70=.e6472662-a2c2-4cc8-a5d6-2fdcc1e4ccac@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <hOSi_AH9jXfKt1WUwy1WkhEoll8BW3zij46ChaGqH70=.e6472662-a2c2-4cc8-a5d6-2fdcc1e4ccac@github.com>
Message-ID: <XFXuEjbb1pLdqs6fOnPhPf57GUcKNVkwF6O0tNCbPl4=.79bb966b-c1f1-4b1c-8bd2-6ddc6337e48a@github.com>

On Wed, 23 Jun 2021 12:40:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>> 
>> Tests: tier1,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Build changes look ok.

@erikj79 Thanks for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From minqi at openjdk.java.net  Wed Jun 23 16:23:27 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 16:23:27 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <4cA-IeJzL12NOGb5ZkIhFAsn2_twoh3vdGz-thq5Qgs=.62337973-1c2f-457c-8883-e79957f0ee47@github.com>

On Wed, 23 Jun 2021 06:08:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_
> 
> Hi Yumin,
> 
> On 23/06/2021 4:19 pm, Yumin Qi wrote:
> 
> > Hi, Please review
> > systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> I'm not really seeing a consistent or recognisable naming pattern here.
> We seem to have a mix of:
> 
> - cds/foo.cpp
> - cds/fooShared.cpp
> - cds/sharedFoo.cpp
> 
> Can we establish a simple naming scheme here?
> 
> Thanks,
> David

Thanks David. I was thinking of that too. The best practice is for a class Foo we have foo.hpp for definition and foo.cpp for implementation. Here indeed exists non-consistency that I put DumpTime/RunTtime in a single file. Let me double check and update.
Yumin

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From xliu at openjdk.java.net  Wed Jun 23 16:44:26 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Jun 2021 16:44:26 GMT
Subject: RFR: 8268855: Cleanup name handling in the Thread class and
 subclasses
In-Reply-To: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
References: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
Message-ID: <0kvvnE-iqCKtFJ2BrscFpXUgF-dnJ8QHuVWjYKuYX_Y=.85ead74c-80c2-4446-9940-64f7ace7eebe@github.com>

On Wed, 23 Jun 2021 06:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small cleanup item.
> 
> We can simplify and cleanup up name() management:
> 
> - make name() return "const char *" and only cast away constness at API boundaries when essential
> - add type_name() so that we can avoid code like "if (t->is_VM_Thread()) print("VMThread");
> - Rename JavaThread::get_thread_name() to name() (no need for the extra indirection)
> 
> There are a couple of minor changes to the appearance of some internal threads in the hs_err log e.g.
> 
>   0x000055af03e5b1b0 WatcherThread [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> is now:
> 
>   0x000055af03e5b1b0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> but this shouldn't affect anything and makes things more consistent.
> 
> Notes: 
> 
> 1. While "override" is the ideal style when declaring overriding methods it has to be applied to all virtual methods in a class. So unless "override" is already used in a class, I did not start using it. I have filed a separate RFE to convert the Thread classes to use "override" consistently.
> 2.  While there is no need to redeclare a virtual method as "virtual" I kept to the existing style in those classes where changes were made.
> 3. I did not override type_name() for all the JavaThread subclasses as it seemed unnecessary, but happy to hear other views on this.
> 
> Testing (in progress):
>  - All builds in tiers 1-5
>  - GHA
>  - tiers 1-3 as a sanity test
> 
> Thanks,
> David

LGTM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4569

From rrich at openjdk.java.net  Wed Jun 23 17:03:38 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 23 Jun 2021 17:03:38 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v5]
In-Reply-To: <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
Message-ID: <18E520rbaxnUxCGlWCqkc_I5cHwA7dvlCVGIFNEY0Ds=.95cb0673-790a-43a2-836d-1417223df845@github.com>

On Mon, 21 Jun 2021 14:49:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Un-ProblemList serviceability tests (8268574 and 8268644)

Hi Patricio,

ppc64le test results are available now. There's no failure related to this change.

Thanks for your patience,
Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From rrich at openjdk.java.net  Wed Jun 23 17:11:32 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 23 Jun 2021 17:11:32 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v5]
In-Reply-To: <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
Message-ID: <Dk_nvgY_H0-sKHILQxoTKoKsvCJEN1FMqi2aHJUfwXg=.f1edcc50-ab26-4557-924f-13762fa703e5@github.com>

On Mon, 21 Jun 2021 14:49:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Un-ProblemList serviceability tests (8268574 and 8268644)

Hi Patricio,

as stated before I've reviewed the part of this change that is related to JDK-8227745 and found it to be good.

Good thing to get rid of so much complex code!

Thanks, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Wed Jun 23 17:41:31 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 23 Jun 2021 17:41:31 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v5]
In-Reply-To: <Dk_nvgY_H0-sKHILQxoTKoKsvCJEN1FMqi2aHJUfwXg=.f1edcc50-ab26-4557-924f-13762fa703e5@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <YKeaohayRLGQKtvTv-Lgyx8e_AIvjXKlWNk7Yt9ercg=.bfcd879d-7b98-432c-bf1b-2443cccc41fd@github.com>
 <Dk_nvgY_H0-sKHILQxoTKoKsvCJEN1FMqi2aHJUfwXg=.f1edcc50-ab26-4557-924f-13762fa703e5@github.com>
Message-ID: <7JM-MMFwRNovuAzdpYoqrzXKUujvGbqaQDb4m-I12wk=.f1b26972-5f1f-4fa6-b29c-1cd8723d3b48@github.com>

On Wed, 23 Jun 2021 17:08:12 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Patricio,
> 
> as stated before I've reviewed the part of this change that is related to JDK-8227745 and found it to be good.
> 
> Good thing to get rid of so much complex code!
> 
Great, thanks for reviewing and all the testing Richard!

Patricio

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Wed Jun 23 17:57:34 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 23 Jun 2021 17:57:34 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v6]
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <ZCflZ93FHVzEuOJsIfFiOPfgDTOwg4HHilh3WR6xKhE=.6ef7ccbb-5e8e-4c80-94eb-a5a643a745aa@github.com>

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - remove extra whitespace
 - Merge master
 - Un-ProblemList serviceability tests (8268574 and 8268644)
 - restore run in EATests.java
 - Dan's comments
 - remove test Test8062950.java + fix commments
 - fix comment in vm_version_ppc.cpp
 - Update java manpage
 - 8256425: Obsolete Biased Locking in JDK 18

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4522/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=05
  Stats: 5328 lines in 165 files changed: 66 ins; 5034 del; 228 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Wed Jun 23 18:15:26 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 23 Jun 2021 18:15:26 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v7]
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <kjWsHi83E1apOiaObyZ__3YVBuq97PvkxXlQ8OlPyqw=.844440a8-597d-477d-ba1f-6852c5e69ac4@github.com>

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  fix cast in added whitebox method after 8268368

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4522/files
  - new: https://git.openjdk.java.net/jdk/pull/4522/files/8d10c0e2..a1164afb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4522&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4522/head:pull/4522

PR: https://git.openjdk.java.net/jdk/pull/4522

From minqi at openjdk.java.net  Wed Jun 23 18:19:47 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 18:19:47 GMT
Subject: RFR: 8267075: jcmd VM.cds should print directory of the output files
Message-ID: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>

Hi, Please review the simple change for jcmd VM.cds to print directory of output file.
The printout will print out absolute file path, also a test scenario added.

Tests: tier1,tier2,tier3,tier4

Thanks
Yumin

-------------

Commit messages:
 - 8267075: jcmd VM.cds should print directory of the output files

Changes: https://git.openjdk.java.net/jdk/pull/4576/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4576&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267075
  Stats: 35 lines in 3 files changed: 27 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4576.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4576/head:pull/4576

PR: https://git.openjdk.java.net/jdk/pull/4576

From xliu at openjdk.java.net  Wed Jun 23 20:25:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Jun 2021 20:25:37 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically change
 tags and decorators
Message-ID: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>

This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
is that previous flush() can't guarantee flush all pending messages in AsyncLog
buffer. This patch implements flush() using a synchronizaton token and waits for
completion. This approach isn't MT-safe but it can serialize all flush() calls in
a thread. 

Two concurrent tests are appended to cover the hazard cases.
This patch also comments LogConfiguration::configure_output() MT-safety.

-------------

Commit messages:
 - 8267952: async logging supports to dynamically change tags and decorators

Changes: https://git.openjdk.java.net/jdk17/pull/130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267952
  Stats: 195 lines in 9 files changed: 159 ins; 14 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/130/head:pull/130

PR: https://git.openjdk.java.net/jdk17/pull/130

From ccheung at openjdk.java.net  Wed Jun 23 20:43:35 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 23 Jun 2021 20:43:35 GMT
Subject: RFR: 8267075: jcmd VM.cds should print directory of the output
 files
In-Reply-To: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
References: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
Message-ID: <gVIknNg5W0nhkiQQzk4cfps23I4qpBFqBP5H3Y2eiPU=.d6405785-6910-494b-80c9-641585a95e4f@github.com>

On Wed, 23 Jun 2021 18:11:47 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review the simple change for jcmd VM.cds to print directory of output file.
> The printout will print out absolute file path, also a test scenario added.
> 
> Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Code changes look good. Just couple of comments in the test case.

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 48:

> 46: public class JCmdTestFileSafety extends JCmdTestDumpBase {
> 47:     static final String promtStdout = "please check stdout file";
> 48:     static final String promtStderr = "or stderr file";

Could you change the variable names to `promptStdout` and `promptStderr` instead?

Please also add the bug id to the `@bug`.

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 53:

> 51:        String stdText = output.getOutput();
> 52:        if (stdText.contains(promtStdout) &&
> 53:            stdText.contains(promtStderr)) {

What if either `promtStdout` or `promtStderr` is not found in stdout, should a RuntimeException be thrown as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4576

From minqi at openjdk.java.net  Wed Jun 23 20:45:49 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 20:45:49 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v2]
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <kBSLkBeRvyTHEfGicPHVnIDnCv-Nb0zjvfvZv3_xXBU=.c1c3518b-1197-4734-a460-854bda73e56f@github.com>

> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Split further sharedClassInfo.hpp to dumpTimeSharedClassInfo.hpp and runTimeSharedClassInfo.hpp to conform to simple rule of separation of definition and implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4568/files
  - new: https://git.openjdk.java.net/jdk/pull/4568/files/e3cd258f..8d104acf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=00-01

  Stats: 1328 lines in 11 files changed: 713 ins; 611 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4568/head:pull/4568

PR: https://git.openjdk.java.net/jdk/pull/4568

From minqi at openjdk.java.net  Wed Jun 23 22:17:27 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 22:17:27 GMT
Subject: RFR: 8267075: jcmd VM.cds should print directory of the output
 files
In-Reply-To: <gVIknNg5W0nhkiQQzk4cfps23I4qpBFqBP5H3Y2eiPU=.d6405785-6910-494b-80c9-641585a95e4f@github.com>
References: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
 <gVIknNg5W0nhkiQQzk4cfps23I4qpBFqBP5H3Y2eiPU=.d6405785-6910-494b-80c9-641585a95e4f@github.com>
Message-ID: <FZ2TXr-JBm0qRErQBF72d3n0N__DhpM77qrUhSa1D6M=.1e70db0c-d7dc-492b-a1aa-c54fdc06b5e0@github.com>

On Wed, 23 Jun 2021 20:40:22 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Hi, Please review the simple change for jcmd VM.cds to print directory of output file.
>> The printout will print out absolute file path, also a test scenario added.
>> 
>> Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 53:
> 
>> 51:        String stdText = output.getOutput();
>> 52:        if (stdText.contains(promtStdout) &&
>> 53:            stdText.contains(promtStderr)) {
> 
> What if either `promtStdout` or `promtStderr` is not found in stdout, should a RuntimeException be thrown as well?

The exception could be other type and without containing those two strings. It should leave to the default processing. Only with those two messaged found, we check if the file with a absolute path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4576

From coleenp at openjdk.java.net  Wed Jun 23 22:32:29 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 22:32:29 GMT
Subject: RFR: 8268855: Cleanup name handling in the Thread class and
 subclasses
In-Reply-To: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
References: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
Message-ID: <JwWrg7d9kvUfm2-oLEOse-jAjKxuq2f6_BR-6TY56K0=.95f91822-6043-4ad7-9dcc-392ff6841f88@github.com>

On Wed, 23 Jun 2021 06:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small cleanup item.
> 
> We can simplify and cleanup up name() management:
> 
> - make name() return "const char *" and only cast away constness at API boundaries when essential
> - add type_name() so that we can avoid code like "if (t->is_VM_Thread()) print("VMThread");
> - Rename JavaThread::get_thread_name() to name() (no need for the extra indirection)
> 
> There are a couple of minor changes to the appearance of some internal threads in the hs_err log e.g.
> 
>   0x000055af03e5b1b0 WatcherThread [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> is now:
> 
>   0x000055af03e5b1b0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> but this shouldn't affect anything and makes things more consistent.
> 
> Notes: 
> 
> 1. While "override" is the ideal style when declaring overriding methods it has to be applied to all virtual methods in a class. So unless "override" is already used in a class, I did not start using it. I have filed a separate RFE to convert the Thread classes to use "override" consistently.
> 2.  While there is no need to redeclare a virtual method as "virtual" I kept to the existing style in those classes where changes were made.
> 3. I did not override type_name() for all the JavaThread subclasses as it seemed unnecessary, but happy to hear other views on this.
> 
> Testing (in progress):
>  - All builds in tiers 1-5
>  - GHA
>  - tiers 1-3 as a sanity test
> 
> Thanks,
> David

This looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4569

From david.holmes at oracle.com  Wed Jun 23 22:37:33 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 24 Jun 2021 08:37:33 +1000
Subject: RFR: 8268821: Split systemDictionaryShared.cpp
In-Reply-To: <4cA-IeJzL12NOGb5ZkIhFAsn2_twoh3vdGz-thq5Qgs=.62337973-1c2f-457c-8883-e79957f0ee47@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <4cA-IeJzL12NOGb5ZkIhFAsn2_twoh3vdGz-thq5Qgs=.62337973-1c2f-457c-8883-e79957f0ee47@github.com>
Message-ID: <82894b15-80af-8f8f-f6e0-9d009f210be7@oracle.com>

On 24/06/2021 2:23 am, Yumin Qi wrote:
> On Wed, 23 Jun 2021 06:08:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:
> 
>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>>
>> Tests: tier1,tier3,tier4
>>
>> Thanks
>> Yumin
> 
>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_
>>
>> Hi Yumin,
>>
>> On 23/06/2021 4:19 pm, Yumin Qi wrote:
>>
>>> Hi, Please review
>>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>>
>> I'm not really seeing a consistent or recognisable naming pattern here.
>> We seem to have a mix of:
>>
>> - cds/foo.cpp
>> - cds/fooShared.cpp
>> - cds/sharedFoo.cpp
>>
>> Can we establish a simple naming scheme here?
>>
>> Thanks,
>> David
> 
> Thanks David. I was thinking of that too. The best practice is for a class Foo we have foo.hpp for definition and foo.cpp for implementation. Here indeed exists non-consistency that I put DumpTime/RunTtime in a single file. Let me double check and update.

That's not what I was saying. I'm talking about the names of the cpp 
file and whether they contain "shared" and whether it is a prefix or 
postfix. There doesn't seem to be a consistent naming scheme employed here.

Thanks,
David

> Yumin
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4568
> 

From ccheung at openjdk.java.net  Wed Jun 23 22:37:36 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 23 Jun 2021 22:37:36 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v2]
In-Reply-To: <kBSLkBeRvyTHEfGicPHVnIDnCv-Nb0zjvfvZv3_xXBU=.c1c3518b-1197-4734-a460-854bda73e56f@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <kBSLkBeRvyTHEfGicPHVnIDnCv-Nb0zjvfvZv3_xXBU=.c1c3518b-1197-4734-a460-854bda73e56f@github.com>
Message-ID: <LeRwctuJIAdRaUSYFEkX2puIEQQGFpfPJrjrNZ9RSSk=.da667eb9-1db8-444f-910b-2e9bbe82c21b@github.com>

On Wed, 23 Jun 2021 20:45:49 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>> 
>> Tests: tier1,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split further sharedClassInfo.hpp to dumpTimeSharedClassInfo.hpp and runTimeSharedClassInfo.hpp to conform to simple rule of separation of definition and implementation

Looks good. Few minor comments.

src/hotspot/share/cds/cdsProtectionDomain.cpp line 34:

> 32: #include "classfile/vmClasses.hpp"
> 33: #include "classfile/vmSymbols.hpp"
> 34: #include "classfile/symbolTable.hpp"

Please move line 34 before line 31.

src/hotspot/share/cds/dumpTimeSharedClassInfo.hpp line 31:

> 29: #include "cds/archiveBuilder.hpp"
> 30: #include "cds/archiveUtils.hpp"
> 31: #include "cds/metaspaceShared.hpp"

Please move line 28 after line 31.

src/hotspot/share/cds/metaspaceShared.cpp line 35:

> 33: #include "cds/lambdaFormInvokers.hpp"
> 34: #include "cds/metaspaceShared.hpp"
> 35: #include "cds/cdsProtectionDomain.hpp"

This line should be after line 27.

src/hotspot/share/classfile/systemDictionaryShared.hpp line 291:

> 289:   static void start_dumping() NOT_CDS_RETURN;
> 290:   static bool is_supported_invokedynamic(BootstrapInfo* bsi) NOT_CDS_RETURN_(false);
> 291:   static void dd_to_dump_time_lambda_proxy_class_dictionary(LambdaProxyClassKey key, InstanceKlass* proxy_klass);

I don't think this is being referenced.

-------------

Changes requested by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4568

From minqi at openjdk.java.net  Wed Jun 23 23:09:46 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 23 Jun 2021 23:09:46 GMT
Subject: RFR: 8267075: jcmd VM.cds should print directory of the output
 files [v2]
In-Reply-To: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
References: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
Message-ID: <8AGEyjBN0H__1zJ42gqOGSX_bpvM6KnPLqyi9ihPa0Y=.723995ec-70f4-473c-94eb-1a621556c6ae@github.com>

> Hi, Please review the simple change for jcmd VM.cds to print directory of output file.
> The printout will print out absolute file path, also a test scenario added.
> 
> Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fix string name for prompt

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4576/files
  - new: https://git.openjdk.java.net/jdk/pull/4576/files/e78f7043..2ef28e06

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4576&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4576&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4576.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4576/head:pull/4576

PR: https://git.openjdk.java.net/jdk/pull/4576

From minqi at openjdk.java.net  Thu Jun 24 00:33:26 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 24 Jun 2021 00:33:26 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v2]
In-Reply-To: <kBSLkBeRvyTHEfGicPHVnIDnCv-Nb0zjvfvZv3_xXBU=.c1c3518b-1197-4734-a460-854bda73e56f@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <kBSLkBeRvyTHEfGicPHVnIDnCv-Nb0zjvfvZv3_xXBU=.c1c3518b-1197-4734-a460-854bda73e56f@github.com>
Message-ID: <UHhgqQIDPRp5KQr5DzrK9rX_gspP9akNr0TrcjjF2yY=.aaad4c07-2a75-4667-b993-de710b483feb@github.com>

On Wed, 23 Jun 2021 20:45:49 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>> 
>> Tests: tier1,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split further sharedClassInfo.hpp to dumpTimeSharedClassInfo.hpp and runTimeSharedClassInfo.hpp to conform to simple rule of separation of definition and implementation

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 24/06/2021 2:23 am, Yumin Qi wrote:
> 
> > On Wed, 23 Jun 2021 06:08:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:
> > > Hi, Please review
> > > systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> > > Tests: tier1,tier3,tier4
> > > Thanks
> > > Yumin
> > 
> > 
> > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_
> > > Hi Yumin,
> > > On 23/06/2021 4:19 pm, Yumin Qi wrote:
> > > > Hi, Please review
> > > > systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> > > 
> > > 
> > > I'm not really seeing a consistent or recognisable naming pattern here.
> > > We seem to have a mix of:
> > > - cds/foo.cpp
> > > - cds/fooShared.cpp
> > > - cds/sharedFoo.cpp
> > > Can we establish a simple naming scheme here?
> > > Thanks,
> > > David
> > 
> > 
> > Thanks David. I was thinking of that too. The best practice is for a class Foo we have foo.hpp for definition and foo.cpp for implementation. Here indeed exists non-consistency that I put DumpTime/RunTtime in a single file. Let me double check and update.
> 
> That's not what I was saying. I'm talking about the names of the cpp
> file and whether they contain "shared" and whether it is a prefix or
> postfix. There doesn't seem to be a consistent naming scheme employed here.
That comes from day one.  The case class FooShared is like 
cds/fooShared.[ch]pp
Usually it is for a class with counterpart of a non-shared version, like Metaspace, SystemDictionary etc.
The classes [DumpTime/RunTime]SharedClassInfo are used for shared only, they don't have non-shared version. The "Shared" embedded just an indication of used in CDS, without it is OK i think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From dholmes at openjdk.java.net  Thu Jun 24 00:55:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 00:55:33 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
Message-ID: <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>

On Wed, 23 Jun 2021 20:18:32 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
> is that previous flush() can't guarantee flush all pending messages in AsyncLog
> buffer. This patch implements flush() using a synchronizaton token and waits for
> completion. This approach isn't MT-safe but it can serialize all flush() calls in
> a thread. 
> 
> Two concurrent tests are appended to cover the hazard cases.
> This patch also comments LogConfiguration::configure_output() MT-safety.

Hi Xin,

Thank you for your patience and perseverance with this. 

This looks good to me now. The flush token seems to work well and is preferable to potentially blocking the async log thread.

I have a number of comments below, but they are all about comments.

I'm running this through our tier 1-7 testing again.

I have one remaining concern, which is just something we need to keep an eye on, and that is the potential for delaying VM termination if the async log writer gets blocked/delayed.

Thanks,
David
-----

src/hotspot/share/logging/logAsyncWriter.cpp line 142:

> 140:     } else if (e->output() == nullptr) {
> 141:       // encounter a flush token. take a record for the time being
> 142:       // and notify flush() after the loop.

Suggestion:
// This is a flush token. Record that we found it and then
// signal the flushing thread after the loop.

src/hotspot/share/logging/logAsyncWriter.cpp line 187:

> 185: }
> 186: 
> 187: // NOT MT-safe! see the comments in the header file.

Suggested comment:
// Inserts a flush token into the async output buffer and waits until the AsyncLog thread
// signals that it has seen it and completed all existing message processing.
// This is method is not MT-safe in itself, but is guarded by another lock in the usual
// usecase - see the comments in the header file for more details.

src/hotspot/share/logging/logAsyncWriter.cpp line 196:

> 194:       AsyncLogMessage token(nullptr, d, nullptr);
> 195: 
> 196:       // not disposable

I don't know what "not disposable" means.

src/hotspot/share/logging/logAsyncWriter.hpp line 124:

> 122: // Once async logging is established, there's no way to turn it off.
> 123: //
> 124: // instance() is MT-safe and returns the pointer of the singleton instance if and only if async logging is enabled and has well

s/well/successfully/

src/hotspot/share/logging/logAsyncWriter.hpp line 127:

> 125: // initialized. Clients can use its return value to determine async logging is established or not.
> 126: //
> 127: // enqueue() is the basic operation of AsyncLogWriter. 2 overloading versions of it are provided to match LogOutput::write().

s/2/Two/

src/hotspot/share/logging/logAsyncWriter.hpp line 133:

> 131: // flush() is designated to flush out all pending messages. MT-safety is not provided. It is no-op if async logging is not in use.
> 132: // In normal JVM termination, flush() is invoked in LogConfiguration::finalize(). When the users change logging configurations
> 133: // via jcmd, LogConfiguration::configure_output() invokes it with the protection of ConfigurationLock.

Suggestion:
// flush() ensures that all pending messages have been written out before it returns. It is not MT-safe
// in itself. When users change the logging configuration via jcmd, LogConfiguration::configure_output()
// calls flush() under the protection of the ConfigurationLock. In addition flush() is called during JVM
// termination, via LogConfiguration::finalize, but that occurs during the VM termination safepoint and so
// no calls to LogConfiguration::configure_output() can be active at the same time.

src/hotspot/share/logging/logAsyncWriter.hpp line 143:

> 141:   // It decreases in AsyncLogWriter::run()
> 142:   Semaphore _sem;
> 143:   Semaphore _flush_sem;

Please add a comment:
// _flush_sem ensures flush() only returns after all enqueued messages are processed

src/hotspot/share/logging/logConfiguration.cpp line 216:

> 214: // MT-SAFETY
> 215: //
> 216: // ConfigurationLock can guarantee that only one thread is performing reconfiguration. This function still needs

// The ConfigurationLock guarantees ...

src/hotspot/share/logging/logConfiguration.cpp line 220:

> 218: // logging allows users to dynamically change tags and decorators of a log output via DCMD(logDiagnosticCommand.hpp).
> 219: //
> 220: // A RCU-style synchronization 'wait_until_no_readers()' is imposed inside of 'ts->set_output_level(output, level)'

s/imposed/used/

src/hotspot/share/logging/logConfiguration.cpp line 221:

> 219: //
> 220: // A RCU-style synchronization 'wait_until_no_readers()' is imposed inside of 'ts->set_output_level(output, level)'
> 221: // if setting has changed. It guarantees that all logs either synchronous writing or enqueuing to the async buffer

// if a setting has changed. It guarantees that all logs, either synchronous writes or enqueuing to the async buffer,

src/hotspot/share/logging/logConfiguration.cpp line 222:

> 220: // A RCU-style synchronization 'wait_until_no_readers()' is imposed inside of 'ts->set_output_level(output, level)'
> 221: // if setting has changed. It guarantees that all logs either synchronous writing or enqueuing to the async buffer
> 222: // see the new tags and decorators. It's worth noting that the synchronization happens even level does not change.

s/even/even if the/

src/hotspot/share/logging/logConfiguration.cpp line 277:

> 275:   //
> 276:   // A flush operation guarantees to all pending messages in buffer are written before returning. Therefore,
> 277:   // the two hazards won't appear after it. It's a nop if async logging is not set.

Given all the other comments I think this can be simplified:

// For async logging we have to ensure that all enqueued messages, which may refer to previous decorators,
// or a soon-to-be-deleted outputs, are written out first. The flush() call ensures this. It is a no-op
// if async logging is not enabled.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/130

From xliu at openjdk.java.net  Thu Jun 24 01:18:28 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 24 Jun 2021 01:18:28 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
Message-ID: <T4GlL6d3NXyzzEX8j7E-B9b9CfXFmg9Db4h2rbjMwK8=.cd004312-cb68-4620-824f-caa754b1ded4@github.com>

On Thu, 24 Jun 2021 00:06:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 196:
> 
>> 194:       AsyncLogMessage token(nullptr, d, nullptr);
>> 195: 
>> 196:       // not disposable
> 
> I don't know what "not disposable" means.

The reason I don't call enqueue_locked() here because it may be dropped due to buffer size. 
This is a control token. if it gets dropped, flush() will get stuck forever. 

not droppable?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From dholmes at openjdk.java.net  Thu Jun 24 01:41:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 01:41:34 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v7]
In-Reply-To: <kjWsHi83E1apOiaObyZ__3YVBuq97PvkxXlQ8OlPyqw=.844440a8-597d-477d-ba1f-6852c5e69ac4@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <kjWsHi83E1apOiaObyZ__3YVBuq97PvkxXlQ8OlPyqw=.844440a8-597d-477d-ba1f-6852c5e69ac4@github.com>
Message-ID: <9dvP65XCwHawwZxRIJaZKZdhtENfJuBS7GPr_0hez5E=.b5e5764e-7a00-4a04-8702-8db5235e14d8@github.com>

On Wed, 23 Jun 2021 18:15:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix cast in added whitebox method after 8268368

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From dholmes at openjdk.java.net  Thu Jun 24 02:57:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 02:57:27 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <T4GlL6d3NXyzzEX8j7E-B9b9CfXFmg9Db4h2rbjMwK8=.cd004312-cb68-4620-824f-caa754b1ded4@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
 <T4GlL6d3NXyzzEX8j7E-B9b9CfXFmg9Db4h2rbjMwK8=.cd004312-cb68-4620-824f-caa754b1ded4@github.com>
Message-ID: <KcUOtgoQINjt_HlomQuZNZbOnKZmCEZIbr6ai7bhxx4=.b295ed51-32e9-497b-8990-1cf451dec42f@github.com>

On Thu, 24 Jun 2021 01:15:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 196:
>> 
>>> 194:       AsyncLogMessage token(nullptr, d, nullptr);
>>> 195: 
>>> 196:       // not disposable
>> 
>> I don't know what "not disposable" means.
>
> The reason I don't call enqueue_locked() here because it may be dropped due to buffer size. 
> This is a control token. if it gets dropped, flush() will get stuck forever. 
> 
> not droppable?

How about:
// Push directly in-case we are at logical max capacity, as this must not get dropped

I'm curious now about the fact the buffer size seems only a logical size constraint not an actual out-of-space constraint.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From david.holmes at oracle.com  Thu Jun 24 03:11:38 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 24 Jun 2021 13:11:38 +1000
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
Message-ID: <03485cc8-7adb-d227-5cfc-0a6e00d3dd4f@oracle.com>

On 24/06/2021 10:55 am, David Holmes wrote:
> On Wed, 23 Jun 2021 20:18:32 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread.
>>
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
> 
> Hi Xin,
> 
> Thank you for your patience and perseverance with this.
> 
> This looks good to me now. The flush token seems to work well and is preferable to potentially blocking the async log thread.
> 
> I have a number of comments below, but they are all about comments.
> 
> I'm running this through our tier 1-7 testing again.

The test passed in all tiers - which is good.

One oddity is that the test log shows at the end:

Warning: asynclog is OFF.
Warning: asynclog is OFF.
Warning: asynclog is OFF.

and I have grepped the source code and the tests and cannot find where 
this message is coming from. So it is unclear to me if this is 
normal/expected or whether there is something that needs attention here?

Thanks,
David
-----

> I have one remaining concern, which is just something we need to keep an eye on, and that is the potential for delaying VM termination if the async log writer gets blocked/delayed.
> 
> Thanks,
> David
> -----
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 142:
> 
>> 140:     } else if (e->output() == nullptr) {
>> 141:       // encounter a flush token. take a record for the time being
>> 142:       // and notify flush() after the loop.
> 
> Suggestion:
> // This is a flush token. Record that we found it and then
> // signal the flushing thread after the loop.
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 187:
> 
>> 185: }
>> 186:
>> 187: // NOT MT-safe! see the comments in the header file.
> 
> Suggested comment:
> // Inserts a flush token into the async output buffer and waits until the AsyncLog thread
> // signals that it has seen it and completed all existing message processing.
> // This is method is not MT-safe in itself, but is guarded by another lock in the usual
> // usecase - see the comments in the header file for more details.
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 196:
> 
>> 194:       AsyncLogMessage token(nullptr, d, nullptr);
>> 195:
>> 196:       // not disposable
> 
> I don't know what "not disposable" means.
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 124:
> 
>> 122: // Once async logging is established, there's no way to turn it off.
>> 123: //
>> 124: // instance() is MT-safe and returns the pointer of the singleton instance if and only if async logging is enabled and has well
> 
> s/well/successfully/
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 127:
> 
>> 125: // initialized. Clients can use its return value to determine async logging is established or not.
>> 126: //
>> 127: // enqueue() is the basic operation of AsyncLogWriter. 2 overloading versions of it are provided to match LogOutput::write().
> 
> s/2/Two/
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 133:
> 
>> 131: // flush() is designated to flush out all pending messages. MT-safety is not provided. It is no-op if async logging is not in use.
>> 132: // In normal JVM termination, flush() is invoked in LogConfiguration::finalize(). When the users change logging configurations
>> 133: // via jcmd, LogConfiguration::configure_output() invokes it with the protection of ConfigurationLock.
> 
> Suggestion:
> // flush() ensures that all pending messages have been written out before it returns. It is not MT-safe
> // in itself. When users change the logging configuration via jcmd, LogConfiguration::configure_output()
> // calls flush() under the protection of the ConfigurationLock. In addition flush() is called during JVM
> // termination, via LogConfiguration::finalize, but that occurs during the VM termination safepoint and so
> // no calls to LogConfiguration::configure_output() can be active at the same time.
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 143:
> 
>> 141:   // It decreases in AsyncLogWriter::run()
>> 142:   Semaphore _sem;
>> 143:   Semaphore _flush_sem;
> 
> Please add a comment:
> // _flush_sem ensures flush() only returns after all enqueued messages are processed
> 
> src/hotspot/share/logging/logConfiguration.cpp line 216:
> 
>> 214: // MT-SAFETY
>> 215: //
>> 216: // ConfigurationLock can guarantee that only one thread is performing reconfiguration. This function still needs
> 
> // The ConfigurationLock guarantees ...
> 
> src/hotspot/share/logging/logConfiguration.cpp line 220:
> 
>> 218: // logging allows users to dynamically change tags and decorators of a log output via DCMD(logDiagnosticCommand.hpp).
>> 219: //
>> 220: // A RCU-style synchronization 'wait_until_no_readers()' is imposed inside of 'ts->set_output_level(output, level)'
> 
> s/imposed/used/
> 
> src/hotspot/share/logging/logConfiguration.cpp line 221:
> 
>> 219: //
>> 220: // A RCU-style synchronization 'wait_until_no_readers()' is imposed inside of 'ts->set_output_level(output, level)'
>> 221: // if setting has changed. It guarantees that all logs either synchronous writing or enqueuing to the async buffer
> 
> // if a setting has changed. It guarantees that all logs, either synchronous writes or enqueuing to the async buffer,
> 
> src/hotspot/share/logging/logConfiguration.cpp line 222:
> 
>> 220: // A RCU-style synchronization 'wait_until_no_readers()' is imposed inside of 'ts->set_output_level(output, level)'
>> 221: // if setting has changed. It guarantees that all logs either synchronous writing or enqueuing to the async buffer
>> 222: // see the new tags and decorators. It's worth noting that the synchronization happens even level does not change.
> 
> s/even/even if the/
> 
> src/hotspot/share/logging/logConfiguration.cpp line 277:
> 
>> 275:   //
>> 276:   // A flush operation guarantees to all pending messages in buffer are written before returning. Therefore,
>> 277:   // the two hazards won't appear after it. It's a nop if async logging is not set.
> 
> Given all the other comments I think this can be simplified:
> 
> // For async logging we have to ensure that all enqueued messages, which may refer to previous decorators,
> // or a soon-to-be-deleted outputs, are written out first. The flush() call ensures this. It is a no-op
> // if async logging is not enabled.
> 
> -------------
> 
> Changes requested by dholmes (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk17/pull/130
> 

From minqi at openjdk.java.net  Thu Jun 24 03:11:35 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 24 Jun 2021 03:11:35 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v3]
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <bJX0xP1Wzuf74sP18B3V2VCK_kyktlkcDmyanwqDUhc=.ecd4b1ed-54f4-4a1c-be79-85ccfb020a48@github.com>

> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Reorder including header files, remove unused function dd_to_dump_time_lambda_proxy_class_dictionary

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4568/files
  - new: https://git.openjdk.java.net/jdk/pull/4568/files/8d104acf..438d54da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=01-02

  Stats: 11 lines in 4 files changed: 4 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4568/head:pull/4568

PR: https://git.openjdk.java.net/jdk/pull/4568

From ccheung at openjdk.java.net  Thu Jun 24 04:16:32 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 04:16:32 GMT
Subject: RFR: 8267075: jcmd VM.cds should print directory of the output
 files [v2]
In-Reply-To: <8AGEyjBN0H__1zJ42gqOGSX_bpvM6KnPLqyi9ihPa0Y=.723995ec-70f4-473c-94eb-1a621556c6ae@github.com>
References: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
 <8AGEyjBN0H__1zJ42gqOGSX_bpvM6KnPLqyi9ihPa0Y=.723995ec-70f4-473c-94eb-1a621556c6ae@github.com>
Message-ID: <zdn0ZhC1PkjEU2MzqyU-3m7FBDIFvC-N3ICja2-0BJI=.64533c38-8eb5-4cca-af96-64f1b353f5d5@github.com>

On Wed, 23 Jun 2021 23:09:46 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review the simple change for jcmd VM.cds to print directory of output file.
>> The printout will print out absolute file path, also a test scenario added.
>> 
>> Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix string name for prompt

Looks good.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4576

From ccheung at openjdk.java.net  Thu Jun 24 04:21:30 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 04:21:30 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v3]
In-Reply-To: <bJX0xP1Wzuf74sP18B3V2VCK_kyktlkcDmyanwqDUhc=.ecd4b1ed-54f4-4a1c-be79-85ccfb020a48@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <bJX0xP1Wzuf74sP18B3V2VCK_kyktlkcDmyanwqDUhc=.ecd4b1ed-54f4-4a1c-be79-85ccfb020a48@github.com>
Message-ID: <-TM1O8roXqQEWWknitgwOZ16lrJprUfM9JPfia2tflE=.b5fb1e42-5f48-468d-a13d-01254a2d8074@github.com>

On Thu, 24 Jun 2021 03:11:35 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>> 
>> Tests: tier1,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorder including header files, remove unused function dd_to_dump_time_lambda_proxy_class_dictionary

> > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> > On 24/06/2021 2:23 am, Yumin Qi wrote:
> > > On Wed, 23 Jun 2021 06:08:41 GMT, Yumin Qi  wrote:
> > > > Hi, Please review
> > > > systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> > > > Tests: tier1,tier3,tier4
> > > > Thanks
> > > > Yumin
> > > 
> > > 
> > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_
> > > > Hi Yumin,
> > > > On 23/06/2021 4:19 pm, Yumin Qi wrote:
> > > > > Hi, Please review
> > > > > systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> > > > 
> > > > 
> > > > I'm not really seeing a consistent or recognisable naming pattern here.
> > > > We seem to have a mix of:
> > > > 
> > > > * cds/foo.cpp
> > > > * cds/fooShared.cpp
> > > > * cds/sharedFoo.cpp
> > > >   Can we establish a simple naming scheme here?
> > > >   Thanks,
> > > >   David
> > > 
> > > 
> > > Thanks David. I was thinking of that too. The best practice is for a class Foo we have foo.hpp for definition and foo.cpp for implementation. Here indeed exists non-consistency that I put DumpTime/RunTtime in a single file. Let me double check and update.
> > 
> > 
> > That's not what I was saying. I'm talking about the names of the cpp
> > file and whether they contain "shared" and whether it is a prefix or
> > postfix. There doesn't seem to be a consistent naming scheme employed here.
> 
> That comes from day one. The case class FooShared is like
> cds/fooShared.[ch]pp
> Usually it is for a class with counterpart of a non-shared version, like Metaspace, SystemDictionary etc.
> The classes [DumpTime/RunTime]SharedClassInfo are used for shared only, they don't have non-shared version. The "Shared" embedded just an indication of used in CDS, without it is OK i think.

I agree that it's fine to drop the word "Shared" from the [DumpTime/RunTime]SharedClassInfo so the the new files could be named [dump|run]TimeClassInfo.[c|h]pp instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From xliu at openjdk.java.net  Thu Jun 24 04:33:28 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 24 Jun 2021 04:33:28 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
Message-ID: <-p8ZzU3IyGQwSPVVcstVoh8C8H_7R9BEt_8kkaOErUw=.0bea2005-c2b1-4f38-8153-a3c768ee5050@github.com>

On Wed, 23 Jun 2021 20:18:32 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
> is that previous flush() can't guarantee flush all pending messages in AsyncLog
> buffer. This patch implements flush() using a synchronizaton token and waits for
> completion. This approach isn't MT-safe but it can serialize all flush() calls in
> a thread. 
> 
> Two concurrent tests are appended to cover the hazard cases.
> This patch also comments LogConfiguration::configure_output() MT-safety.

hi, David, 
> I have one remaining concern, which is just something we need to keep an eye on, and that is the potential for delaying VM termination if the async log writer gets blocked/delayed.

We discussed this before. Yes, if "write_blocking()" does block on I/O part, flush() is blocked.  We have this issue before, and synchronous logging has this issue as well.    I think Async logging is better than sync logging on this because at least JVM got stuck at termination instead of any safepoint if it did happen.  

It isn't perfect. Ideally, we can use flush_sem.wait(timeout) if Semaphore::wait supports timeout for all platforms. 

> I'm curious now about the fact the buffer size seems only a logical size constraint not an actual out-of-space constraint.

We can have an assertion like this. It's because flush() must be thread-safe. The reason I don't enforce it using mutex or yet another semaphore is that current use cases have already been protected. If all flush() are serialized, it means that there's one or none token at any time. therefore, the following assertion is right. Shall I put it back? 

`
assert(_buffer.size() < _buffer_max_size+1, "_buffer is over-sized.");
`

>  Warning: asynclog is OFF.
It is from gtest fixture AsyncLogTest, which is expected. We run those tests in two modes. 
Normally, gtest run this test in synchronous mode. It doesn't test much. 

https://github.com/openjdk/jdk/blob/master/test/hotspot/gtest/logging/test_asynclog.cpp#L37

Thank you for you patience. TBH, I coundn't wrap around my head if you did tell me that handshake problem. 
I will post a new revision to include your feedbacks.

thanks,
--lx

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From david.holmes at oracle.com  Thu Jun 24 04:48:12 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 24 Jun 2021 14:48:12 +1000
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <-p8ZzU3IyGQwSPVVcstVoh8C8H_7R9BEt_8kkaOErUw=.0bea2005-c2b1-4f38-8153-a3c768ee5050@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <-p8ZzU3IyGQwSPVVcstVoh8C8H_7R9BEt_8kkaOErUw=.0bea2005-c2b1-4f38-8153-a3c768ee5050@github.com>
Message-ID: <146e4af3-84e9-5b63-c95f-ce7ceff8f1b0@oracle.com>

On 24/06/2021 2:33 pm, Xin Liu wrote:
> On Wed, 23 Jun 2021 20:18:32 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread.
>>
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
> 
> hi, David,
>> I have one remaining concern, which is just something we need to keep an eye on, and that is the potential for delaying VM termination if the async log writer gets blocked/delayed.
> 
> We discussed this before. Yes, if "write_blocking()" does block on I/O part, flush() is blocked.  We have this issue before, and synchronous logging has this issue as well.    I think Async logging is better than sync logging on this because at least JVM got stuck at termination instead of any safepoint if it did happen.
> 
> It isn't perfect. Ideally, we can use flush_sem.wait(timeout) if Semaphore::wait supports timeout for all platforms.

I agree existing synchronous logging also has a (worse?) problem here. 
Not sure there is a suitable fix as any timeout will race with the 
asyncLog thread again potentially causing the crashes you just fixed.

>> I'm curious now about the fact the buffer size seems only a logical size constraint not an actual out-of-space constraint.
> 
> We can have an assertion like this. It's because flush() must be thread-safe. The reason I don't enforce it using mutex or yet another semaphore is that current use cases have already been protected. If all flush() are serialized, it means that there's one or none token at any time. therefore, the following assertion is right. Shall I put it back?
> 
> `
> assert(_buffer.size() < _buffer_max_size+1, "_buffer is over-sized.");
> `

Not sure where this assertion was.

But that wasn't what I was asking about. I thought we had 
AsyncLogBufferSize because we had a fixed size buffer and hence if the 
buffer were full you couldn't insert the token. BUt I was misremembering 
- the buffer size is not fixed (it is just a linked list) it is the 
number of buffer entries that is limited by AsyncLogBufferSize, to 
ensure we don't consume too much memory. So all is fine here.

>>   Warning: asynclog is OFF.
> It is from gtest fixture AsyncLogTest, which is expected. We run those tests in two modes.
> Normally, gtest run this test in synchronous mode. It doesn't test much.
> 
> https://github.com/openjdk/jdk/blob/master/test/hotspot/gtest/logging/test_asynclog.cpp#L37

Doh! I grepped in hotspot/jtreg by mistake. Thanks for clarifying.

Cheers,
David
-----

> Thank you for you patience. TBH, I coundn't wrap around my head if you did tell me that handshake problem.
> I will post a new revision to include your feedbacks.
> 
> thanks,
> --lx
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/130
> 

From xliu at openjdk.java.net  Thu Jun 24 05:31:27 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 24 Jun 2021 05:31:27 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <KcUOtgoQINjt_HlomQuZNZbOnKZmCEZIbr6ai7bhxx4=.b295ed51-32e9-497b-8990-1cf451dec42f@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
 <T4GlL6d3NXyzzEX8j7E-B9b9CfXFmg9Db4h2rbjMwK8=.cd004312-cb68-4620-824f-caa754b1ded4@github.com>
 <KcUOtgoQINjt_HlomQuZNZbOnKZmCEZIbr6ai7bhxx4=.b295ed51-32e9-497b-8990-1cf451dec42f@github.com>
Message-ID: <oKlQJ-UigZL4SiL5CA5CKMWFZizOzc2V3aJ0dWHx6O0=.ed7b9fbc-63b2-4e00-b100-822aa3b849c5@github.com>

On Thu, 24 Jun 2021 02:54:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The reason I don't call enqueue_locked() here because it may be dropped due to buffer size. 
>> This is a control token. if it gets dropped, flush() will get stuck forever. 
>> 
>> not droppable?
>
> How about:
> // Push directly in-case we are at logical max capacity, as this must not get dropped
> 
> I'm curious now about the fact the buffer size seems only a logical size constraint not an actual out-of-space constraint.

currently, it's a soft limit.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From xliu at openjdk.java.net  Thu Jun 24 05:58:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 24 Jun 2021 05:58:54 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v2]
In-Reply-To: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
Message-ID: <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>

> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
> is that previous flush() can't guarantee flush all pending messages in AsyncLog
> buffer. This patch implements flush() using a synchronizaton token and waits for
> completion. This approach isn't MT-safe but it can serialize all flush() calls in
> a thread. 
> 
> Two concurrent tests are appended to cover the hazard cases.
> This patch also comments LogConfiguration::configure_output() MT-safety.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Update comments according to reviewers's feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/130/files
  - new: https://git.openjdk.java.net/jdk17/pull/130/files/6f15a895..b35073f7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=00-01

  Stats: 28 lines in 3 files changed: 3 ins; 5 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/130/head:pull/130

PR: https://git.openjdk.java.net/jdk17/pull/130

From cgo at openjdk.java.net  Thu Jun 24 12:06:43 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Thu, 24 Jun 2021 12:06:43 GMT
Subject: RFR: 8230797: ARM32-softfp: assertion in
 InterpreterRuntime::resolve_ldc
Message-ID: <ipbid3jY-0Uvn6cFMQoJuKZfuSs_fpCf_r03KamDPnE=.81d49cbf-5163-4b4e-afd5-d6e9e978fe2d@github.com>

Hi,

please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp.

For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV.

I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed.

-------------

Commit messages:
 - Guard resolve ldc assertion.

Changes: https://git.openjdk.java.net/jdk/pull/4582/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4582&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8230797
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4582/head:pull/4582

PR: https://git.openjdk.java.net/jdk/pull/4582

From dholmes at openjdk.java.net  Thu Jun 24 13:11:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 13:11:25 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM [v2]
In-Reply-To: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
 <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com>
Message-ID: <x3Lmkp7sHyM3uYYNcdrmudNUmrF7mgpYjDyoNSNJDJc=.f03ee197-89fe-4e03-919c-1455cd27013e@github.com>

On Wed, 23 Jun 2021 10:44:53 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
>> 
>> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
>> 
>> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds requires compiler2 & revert compilation level detection.

This seems fine to me.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4558

From coleenp at openjdk.java.net  Thu Jun 24 13:18:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 24 Jun 2021 13:18:37 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
Message-ID: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>

This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

-------------

Commit messages:
 - 8269293: ObjectMonitor thread id fields should be 64 bits.

Changes: https://git.openjdk.java.net/jdk/pull/4584/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4584&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269293
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4584.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4584/head:pull/4584

PR: https://git.openjdk.java.net/jdk/pull/4584

From dholmes at openjdk.java.net  Thu Jun 24 13:18:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 13:18:37 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
Message-ID: <gZrRIhC41YT38rrIFhMN37zi81D0nv0AIcdJnIILsvA=.381b667a-c8ae-4b94-bd69-aebe376b83ad@github.com>

On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

Hi Coleen,

Is there any way we can use the JFR type definition "traceid" for this? If not then this looks fine.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4584

From dholmes at openjdk.java.net  Thu Jun 24 13:23:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 13:23:26 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
Message-ID: <HsKH-kF77lnobCQL8SIaquY2XCZhBq4xKFVvTdBMv6g=.7ef3f6c8-4de7-47bf-9bac-c2912838d2bc@github.com>

On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

Note you can build a 32-bit VM and run it on a 64-bit system.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4584

From coleen.phillimore at oracle.com  Thu Jun 24 13:25:56 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 24 Jun 2021 09:25:56 -0400
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <gZrRIhC41YT38rrIFhMN37zi81D0nv0AIcdJnIILsvA=.381b667a-c8ae-4b94-bd69-aebe376b83ad@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
 <gZrRIhC41YT38rrIFhMN37zi81D0nv0AIcdJnIILsvA=.381b667a-c8ae-4b94-bd69-aebe376b83ad@github.com>
Message-ID: <4d82eb1f-55c1-70a9-411b-dafbbd946c08@oracle.com>



On 6/24/21 9:18 AM, David Holmes wrote:
> On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
>> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.
> Hi Coleen,
>
> Is there any way we can use the JFR type definition "traceid" for this? If not then this looks fine.

Thanks for the quick review.? It's pretty awkward to include 
jfr/support/jfrThreadId.hpp in objectMonitor.hpp (JFR is included 
conditionally), so would have to include these fields conditionally, and 
add #if INCLUDE_JFR in lots of places.? It's not nice.

Thanks,
Coleen

>
> Thanks,
> David
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4584


From shade at openjdk.java.net  Thu Jun 24 13:30:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 13:30:26 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <HsKH-kF77lnobCQL8SIaquY2XCZhBq4xKFVvTdBMv6g=.7ef3f6c8-4de7-47bf-9bac-c2912838d2bc@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
 <HsKH-kF77lnobCQL8SIaquY2XCZhBq4xKFVvTdBMv6g=.7ef3f6c8-4de7-47bf-9bac-c2912838d2bc@github.com>
Message-ID: <HgsyeqbCJ-4mShmRcjGZ_g4ySzjgOk9De8q8QrTmnIQ=.6399ecca-718e-444c-9831-b15bee708837@github.com>

On Thu, 24 Jun 2021 13:20:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Note you can build a 32-bit VM and run it on a 64-bit system.

...and GHA would run x86_32 tier1 for you. The patch is unlikely to cause trouble, but just look through GHA results.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4584

From cgo at openjdk.java.net  Thu Jun 24 13:43:29 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Thu, 24 Jun 2021 13:43:29 GMT
Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in
 client VM [v2]
In-Reply-To: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com>
References: <oYaIna409rM9C-WgH0yziJWaP_KOZnlXrdl61HKbXkU=.1d5f14cb-0082-44e5-b801-8d0274c3dba9@github.com>
 <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com>
Message-ID: <j2u2Xea21CCaUHPtcF5xIjjlGBOdOeUWW_tw7B1sZOM=.0370894d-d4c0-4d31-8d73-1be966ac48a9@github.com>

On Wed, 23 Jun 2021 10:44:53 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation.
>> 
>> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used.
>> 
>> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions).
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds requires compiler2 & revert compilation level detection.

Thanks David.
Are you fine with this version as well, @eastig?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4558

From mgronlun at openjdk.java.net  Thu Jun 24 13:49:26 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 24 Jun 2021 13:49:26 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
Message-ID: <BSKjV8L_qvh1pq7aY1rxz_0APtwLh5AT7yelQaN9SXw=.2dd84f1c-93dd-4d53-ba95-3b1a89d59e03@github.com>

On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4584

From minqi at openjdk.java.net  Thu Jun 24 14:56:34 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 24 Jun 2021 14:56:34 GMT
Subject: RFR: 8267075: jcmd VM.cds should print directory of the output
 files [v2]
In-Reply-To: <zdn0ZhC1PkjEU2MzqyU-3m7FBDIFvC-N3ICja2-0BJI=.64533c38-8eb5-4cca-af96-64f1b353f5d5@github.com>
References: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
 <8AGEyjBN0H__1zJ42gqOGSX_bpvM6KnPLqyi9ihPa0Y=.723995ec-70f4-473c-94eb-1a621556c6ae@github.com>
 <zdn0ZhC1PkjEU2MzqyU-3m7FBDIFvC-N3ICja2-0BJI=.64533c38-8eb5-4cca-af96-64f1b353f5d5@github.com>
Message-ID: <-IofyANjkzpkn8KpjkYWP0mKuBZ2_3nlIC1Nw11LNY8=.895ee456-56d7-4644-a8d7-0b5fabc23367@github.com>

On Thu, 24 Jun 2021 04:13:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix string name for prompt
>
> Looks good.

@calvinccheung Thanks for review! Since it is a simple fix, I will integrate without second review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4576

From minqi at openjdk.java.net  Thu Jun 24 14:56:34 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 24 Jun 2021 14:56:34 GMT
Subject: Integrated: 8267075: jcmd VM.cds should print directory of the output
 files
In-Reply-To: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
References: <GRhDZfCAqICu6P6B1VyNj6cqnIe_sjnnWwkT3SD9Cko=.a14f010c-2e3d-4649-b931-0fdd4d947ff6@github.com>
Message-ID: <NHQYTuHYMnG6lcDS5jc7DkgGzgz6ZcWrw_BTG6DvRTk=.5e543401-3897-448f-819b-7a3be60be819@github.com>

On Wed, 23 Jun 2021 18:11:47 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review the simple change for jcmd VM.cds to print directory of output file.
> The printout will print out absolute file path, also a test scenario added.
> 
> Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: 7c31903d
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c31903dd3f2f27de1c352294558a4c1bd6c51e7
Stats:     36 lines in 3 files changed: 27 ins; 1 del; 8 mod

8267075: jcmd VM.cds should print directory of the output files

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk/pull/4576

From dcubed at openjdk.java.net  Thu Jun 24 15:46:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 15:46:27 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
Message-ID: <Y8URVLyiZUqj-98w-AXMQCwScMsjM9-XkCodNYgBc8Q=.17b733a8-4871-4dfa-a996-4e9a5cf8223d@github.com>

On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4584

From dcubed at openjdk.java.net  Thu Jun 24 17:00:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 17:00:53 GMT
Subject: [jdk17] Integrated: 8269307: ProblemList
 java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
 on win-x64
Message-ID: <ey8D6yTN0lAZhHn8KGH-vIRhupa3COMoVNPWYek5v7w=.70e36494-9baa-4963-aedb-28a60e80fb82@github.com>

A trivial fix to ProblemList java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java on win-x64.

-------------

Commit messages:
 - 8269307: ProblemList java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java on win-x64

Changes: https://git.openjdk.java.net/jdk17/pull/136/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=136&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269307
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk17/pull/136

From mikael at openjdk.java.net  Thu Jun 24 17:00:53 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 24 Jun 2021 17:00:53 GMT
Subject: [jdk17] Integrated: 8269307: ProblemList
 java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
 on win-x64
In-Reply-To: <ey8D6yTN0lAZhHn8KGH-vIRhupa3COMoVNPWYek5v7w=.70e36494-9baa-4963-aedb-28a60e80fb82@github.com>
References: <ey8D6yTN0lAZhHn8KGH-vIRhupa3COMoVNPWYek5v7w=.70e36494-9baa-4963-aedb-28a60e80fb82@github.com>
Message-ID: <b6QjAYO5aUkAsNIH_JFYCdetLuk8g01DyAZ3duFhQZY=.71429248-0307-40f3-8fb9-6e72daaf6366@github.com>

On Thu, 24 Jun 2021 16:51:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java on win-x64.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/136

From dcubed at openjdk.java.net  Thu Jun 24 17:00:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 17:00:53 GMT
Subject: [jdk17] Integrated: 8269307: ProblemList
 java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
 on win-x64
In-Reply-To: <b6QjAYO5aUkAsNIH_JFYCdetLuk8g01DyAZ3duFhQZY=.71429248-0307-40f3-8fb9-6e72daaf6366@github.com>
References: <ey8D6yTN0lAZhHn8KGH-vIRhupa3COMoVNPWYek5v7w=.70e36494-9baa-4963-aedb-28a60e80fb82@github.com>
 <b6QjAYO5aUkAsNIH_JFYCdetLuk8g01DyAZ3duFhQZY=.71429248-0307-40f3-8fb9-6e72daaf6366@github.com>
Message-ID: <wDnRh-zdq4G5p-tjZPvYpR6b4OdJZCMW5SyKcHXap1A=.c401b9c3-0d36-4a56-8c84-2394ee991670@github.com>

On Thu, 24 Jun 2021 16:53:47 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java on win-x64.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/136

From dcubed at openjdk.java.net  Thu Jun 24 17:00:54 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 17:00:54 GMT
Subject: [jdk17] Integrated: 8269307: ProblemList
 java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
 on win-x64
In-Reply-To: <ey8D6yTN0lAZhHn8KGH-vIRhupa3COMoVNPWYek5v7w=.70e36494-9baa-4963-aedb-28a60e80fb82@github.com>
References: <ey8D6yTN0lAZhHn8KGH-vIRhupa3COMoVNPWYek5v7w=.70e36494-9baa-4963-aedb-28a60e80fb82@github.com>
Message-ID: <QC5ytwAAK6i5LF89FXixxuL6YqeV2UT8LHcArl8HqPs=.3f611144-279d-41fe-9ac1-df9addee250a@github.com>

On Thu, 24 Jun 2021 16:51:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java on win-x64.

This pull request has now been integrated.

Changeset: 424cc502
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/424cc5025778d69d5b5b70d529184cc2ca305c98
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8269307: ProblemList java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java on win-x64

Reviewed-by: mikael

-------------

PR: https://git.openjdk.java.net/jdk17/pull/136

From pchilanomate at openjdk.java.net  Thu Jun 24 18:58:39 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 24 Jun 2021 18:58:39 GMT
Subject: Integrated: 8256425: Obsolete Biased Locking in JDK 18
In-Reply-To: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
Message-ID: <SPm2As5B3iS1xsI_1MgqLLC45Q7C6UhV2JWP7DdySpA=.22eddd32-023b-40bf-afd1-a447835dccc6@github.com>

On Thu, 17 Jun 2021 15:37:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which handles the removal of biased locking code. 
> 
> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
> 
> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
> 
> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
> 
> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
> 
> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 2fd7943e
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2fd7943ec191559bfb2778305daf82bcc4422028
Stats:     5328 lines in 165 files changed: 66 ins; 5034 del; 228 mod

8256425: Obsolete Biased Locking in JDK 18

Reviewed-by: kvn, dholmes, dcubed, rrich

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From pchilanomate at openjdk.java.net  Thu Jun 24 18:58:38 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 24 Jun 2021 18:58:38 GMT
Subject: RFR: 8256425: Obsolete Biased Locking in JDK 18 [v7]
In-Reply-To: <kjWsHi83E1apOiaObyZ__3YVBuq97PvkxXlQ8OlPyqw=.844440a8-597d-477d-ba1f-6852c5e69ac4@github.com>
References: <c4oofcmYji38pU79XLq5UE1qq_-zS5GW9dYH3U7-LQA=.f17896fd-9e45-4cfd-94d9-7cbda6a1b05b@github.com>
 <kjWsHi83E1apOiaObyZ__3YVBuq97PvkxXlQ8OlPyqw=.844440a8-597d-477d-ba1f-6852c5e69ac4@github.com>
Message-ID: <tcwcmYMSSdG_puzXaRNKkY5LEX1DJKPsTLegWsQ95Ko=.47638a71-79d1-4aaa-97a6-e94eb7f161f1@github.com>

On Wed, 23 Jun 2021 18:15:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which handles the removal of biased locking code. 
>> 
>> The third least significant bit of the markword is now always unused. I didn't try to give it back to the age field as it was prior to biased locking introduction since it will likely be taken away by other projects (probably Valhalla). 
>> 
>> Regarding c1 changes, the scratch register passed to LIRGenerator::monitor_enter() was only used by biased locking code except in ppc, so in all other platforms I removed the scratch parameter from C1_MacroAssembler::lock_object() (except in s390 where it wasn't defined already). 
>> We could probably just always use R0 as a temp register in lock_object() for ppc, since we were already using it as temp in biased_locking_enter(), and remove the scratch parameter from there too. Then we could remove the scratch field from LIR_OpLock. I haven't done that in this patch though.
>> 
>> For c2, type.hpp defined XorXNode, StoreXConditionalNode, LoadXNode and StoreXNode as needed by UseOptoBiasInlining. I see that LoadXNode and StoreXNode are also used by shenandoahSupport so I kept those two defines. I removed only the biased locking comments from the storeIConditional/storeLConditional implementations in .ad files since I don't know if they might be needed.
>> 
>> There are some tests that were only meaningful when run with biased locking enabled so I removed them.
>> 
>> Tested in mach5 tiers 1-7. I tested it builds also on ppc, s390 and arm32 but can't run any tests on those platforms so it would be good if somebody can do some sanity check on those ones.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix cast in added whitebox method after 8268368

Thanks all for reviews and comments!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4522

From dcubed at openjdk.java.net  Thu Jun 24 18:59:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 18:59:39 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
Message-ID: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>

A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

-------------

Commit messages:
 - 8269314: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64

Changes: https://git.openjdk.java.net/jdk17/pull/138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269314
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/138/head:pull/138

PR: https://git.openjdk.java.net/jdk17/pull/138

From ccheung at openjdk.java.net  Thu Jun 24 18:59:39 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 18:59:39 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
Message-ID: <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>

On Thu, 24 Jun 2021 18:51:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

One question.

test/hotspot/jtreg/ProblemList.txt line 113:

> 111: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all
> 112: serviceability/jvmti/ModuleAwareAgents/ThreadStart/MAAThreadStart.java 8225354 windows-all
> 113: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64

Should linux-all be linux-aarch64?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From ccheung at openjdk.java.net  Thu Jun 24 19:10:27 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 19:10:27 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
Message-ID: <QfqwLwbnyBEirHy7IWwyMl-3OQjJk8qZU2cnn6psS6E=.fc52b24b-6e6e-49ec-9fbb-7a8a5ce4e59b@github.com>

On Thu, 24 Jun 2021 18:51:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

Marked as reviewed by ccheung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 19:10:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:10:28 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
 <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>
Message-ID: <luUE_zrOtjlnEoZazqaVS9mUh0eH7K3aVkROIQZCjj4=.7b144e1a-504c-4491-852f-1a939d7a6628@github.com>

On Thu, 24 Jun 2021 18:56:23 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.
>
> test/hotspot/jtreg/ProblemList.txt line 113:
> 
>> 111: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all
>> 112: serviceability/jvmti/ModuleAwareAgents/ThreadStart/MAAThreadStart.java 8225354 windows-all
>> 113: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64
> 
> Should linux-all be linux-aarch64?

No, the entry was previously linux-x64 so I've changed it to linux-all to
cover linux-x64 and linux-aarch64.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From ccheung at openjdk.java.net  Thu Jun 24 19:10:28 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 19:10:28 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <luUE_zrOtjlnEoZazqaVS9mUh0eH7K3aVkROIQZCjj4=.7b144e1a-504c-4491-852f-1a939d7a6628@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
 <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>
 <luUE_zrOtjlnEoZazqaVS9mUh0eH7K3aVkROIQZCjj4=.7b144e1a-504c-4491-852f-1a939d7a6628@github.com>
Message-ID: <Waq3nYLMlHq7CRCQxrMY6FnHtR2nkuuE-jsO2jKMrbw=.6b738c50-815d-4ad0-a360-1ec34eb0b181@github.com>

On Thu, 24 Jun 2021 19:04:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/ProblemList.txt line 113:
>> 
>>> 111: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all
>>> 112: serviceability/jvmti/ModuleAwareAgents/ThreadStart/MAAThreadStart.java 8225354 windows-all
>>> 113: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64
>> 
>> Should linux-all be linux-aarch64?
>
> No, the entry was previously linux-x64 so I've changed it to linux-all to
> cover linux-x64 and linux-aarch64.

Looks good and trivial then.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 19:21:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:21:34 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <QfqwLwbnyBEirHy7IWwyMl-3OQjJk8qZU2cnn6psS6E=.fc52b24b-6e6e-49ec-9fbb-7a8a5ce4e59b@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
 <QfqwLwbnyBEirHy7IWwyMl-3OQjJk8qZU2cnn6psS6E=.fc52b24b-6e6e-49ec-9fbb-7a8a5ce4e59b@github.com>
Message-ID: <mbmMW55hQEr0eMxrSg18oJsKA8dCzv27vitf2dK0Px4=.21da31db-1090-40a8-9753-c690af6432b5@github.com>

On Thu, 24 Jun 2021 19:07:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.
>
> Marked as reviewed by ccheung (Reviewer).

@calvinccheung - Thanks for the fast review (and the sanity check).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 19:27:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:27:40 GMT
Subject: [jdk17] RFR: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
Message-ID: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>

A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.

-------------

Commit messages:
 - 8269315: ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64

Changes: https://git.openjdk.java.net/jdk17/pull/139/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=139&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269315
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/139.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/139/head:pull/139

PR: https://git.openjdk.java.net/jdk17/pull/139

From coleenp at openjdk.java.net  Thu Jun 24 19:38:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 24 Jun 2021 19:38:33 GMT
Subject: RFR: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
Message-ID: <uKlU2ZmmhXGJwfi37ShcpB6A29kK_yscoQF3MDoXbmM=.5b40c955-ddf3-4964-8830-3ba9d5fd7efa@github.com>

On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

Thanks David, Markus and Dan.  The github actions built linux-x86 so that's ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4584

From coleenp at openjdk.java.net  Thu Jun 24 19:38:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 24 Jun 2021 19:38:33 GMT
Subject: Integrated: 8269293: ObjectMonitor thread id fields should be 64 bits.
In-Reply-To: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
References: <_5E4lGqRIId-qTXA__5nNuNrNUtWFC_cp0L5_MsjHtA=.a161949e-4492-46b5-bfff-d24857950bd7@github.com>
Message-ID: <zKdRSSJDq3MIumPfX4M-MnfH-jwtJxZW2OOGl9yQ6ZE=.051b4065-1c9d-42ee-bb58-74363efd0abb@github.com>

On Thu, 24 Jun 2021 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to fix the type of _previous_version_tid and _notifier_tid in ObjectMonitor to be unint64_t.
> Tested with tier1-3 and JFR tests on linux-x64-debug and windows-x64-debug.  I don't have a 32 bit system to test this out on.

This pull request has now been integrated.

Changeset: 42968db1
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42968db173b3caa53b6ad403f1891c41bcc6fb75
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8269293: ObjectMonitor thread id fields should be 64 bits.

Reviewed-by: mgronlun, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/4584

From dcubed at openjdk.java.net  Thu Jun 24 19:46:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:46:00 GMT
Subject: [jdk17] RFR: 8269316: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Linux-X64 -Xcomp
Message-ID: <zQfENUE5yzjWCh6ZhKeplqXiuq08yGNl5Z_nvJthbnU=.065adaea-7386-45e2-91f6-4a3a11934c75@github.com>

A trivial fix to ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Linux-X64 -Xcomp.

-------------

Commit messages:
 - 8269316: ProblemListvmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Linux-X64 -Xcomp

Changes: https://git.openjdk.java.net/jdk17/pull/140/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=140&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269316
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/140.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/140/head:pull/140

PR: https://git.openjdk.java.net/jdk17/pull/140

From dcubed at openjdk.java.net  Thu Jun 24 20:24:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:24:28 GMT
Subject: [jdk17] RFR: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
In-Reply-To: <4G8c0mE6TNqDWh-9_UCe2hR9b2EJzpF33HLJQSBk9RA=.67e4b0d9-9827-4bc7-9cb7-b591d1248a61@github.com>
References: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
 <4G8c0mE6TNqDWh-9_UCe2hR9b2EJzpF33HLJQSBk9RA=.67e4b0d9-9827-4bc7-9cb7-b591d1248a61@github.com>
Message-ID: <W5EvOJFCf4mHRdkusE9KKuCVuOpWdPANCbXsu4QaEls=.74ea91df-c41b-43e7-90d3-cba0cd7ab921@github.com>

On Thu, 24 Jun 2021 20:21:18 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.
>
> Looks good and trivial.

@calvinccheung - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/139

From ccheung at openjdk.java.net  Thu Jun 24 20:24:28 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 20:24:28 GMT
Subject: [jdk17] RFR: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
In-Reply-To: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
References: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
Message-ID: <4G8c0mE6TNqDWh-9_UCe2hR9b2EJzpF33HLJQSBk9RA=.67e4b0d9-9827-4bc7-9cb7-b591d1248a61@github.com>

On Thu, 24 Jun 2021 19:20:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.

Looks good and trivial.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/139

From dcubed at openjdk.java.net  Thu Jun 24 20:25:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:25:03 GMT
Subject: [jdk17] RFR: 8269316: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Linux-X64 -Xcomp
In-Reply-To: <rwFpSUprJqYAh1Z1yRRQ3CBpcqDVTAc5c_SBStof7Hc=.4e79ef75-4b82-4eec-abaf-b0c39df9cd25@github.com>
References: <zQfENUE5yzjWCh6ZhKeplqXiuq08yGNl5Z_nvJthbnU=.065adaea-7386-45e2-91f6-4a3a11934c75@github.com>
 <rwFpSUprJqYAh1Z1yRRQ3CBpcqDVTAc5c_SBStof7Hc=.4e79ef75-4b82-4eec-abaf-b0c39df9cd25@github.com>
Message-ID: <maLMEYtmvXDQ3iWb16uLTSCUYT9qAx5gg0-LdsOMnT0=.0a4a6050-9e19-44b5-af2c-82de168d3647@github.com>

On Thu, 24 Jun 2021 20:21:43 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Linux-X64 -Xcomp.
>
> Looks good and trivial.

@calvinccheung - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/140

From ccheung at openjdk.java.net  Thu Jun 24 20:25:03 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 20:25:03 GMT
Subject: [jdk17] RFR: 8269316: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Linux-X64 -Xcomp
In-Reply-To: <zQfENUE5yzjWCh6ZhKeplqXiuq08yGNl5Z_nvJthbnU=.065adaea-7386-45e2-91f6-4a3a11934c75@github.com>
References: <zQfENUE5yzjWCh6ZhKeplqXiuq08yGNl5Z_nvJthbnU=.065adaea-7386-45e2-91f6-4a3a11934c75@github.com>
Message-ID: <rwFpSUprJqYAh1Z1yRRQ3CBpcqDVTAc5c_SBStof7Hc=.4e79ef75-4b82-4eec-abaf-b0c39df9cd25@github.com>

On Thu, 24 Jun 2021 19:36:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Linux-X64 -Xcomp.

Looks good and trivial.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/140

From dcubed at openjdk.java.net  Thu Jun 24 20:30:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:30:02 GMT
Subject: [jdk17] Integrated: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
In-Reply-To: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
References: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
Message-ID: <PxmHf5TQ86qlbj-7FQhcZnpNhcTmzTg_7CUjjdXeRt4=.a6cf81da-abec-4dbf-8b81-b18180632295@github.com>

On Thu, 24 Jun 2021 19:20:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.

This pull request has now been integrated.

Changeset: 22d86750
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/22d867508514d57faaaa5c515ed5bfc635eb63f6
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8269315: ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk17/pull/139

From dcubed at openjdk.java.net  Thu Jun 24 20:30:11 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:30:11 GMT
Subject: [jdk17] Integrated: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
Message-ID: <moyr7X1M6UOznTCthPD2DjlJCBpbKh_hD-3hxOsZRmg=.6521d048-7b2b-4f15-a297-bcac3fc2fa4f@github.com>

On Thu, 24 Jun 2021 18:51:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

This pull request has now been integrated.

Changeset: 443a79aa
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/443a79aaa191953e948e4732400c58e1311c3673
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269314: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 20:31:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:31:00 GMT
Subject: [jdk17] Integrated: 8269316: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Linux-X64 -Xcomp
In-Reply-To: <zQfENUE5yzjWCh6ZhKeplqXiuq08yGNl5Z_nvJthbnU=.065adaea-7386-45e2-91f6-4a3a11934c75@github.com>
References: <zQfENUE5yzjWCh6ZhKeplqXiuq08yGNl5Z_nvJthbnU=.065adaea-7386-45e2-91f6-4a3a11934c75@github.com>
Message-ID: <MIDSFoHvqUICqXc4HQAARU92FHItqX9u-yfi60tbT-Y=.58d4ae59-fab6-4fbe-aa66-e393c0ed5564@github.com>

On Thu, 24 Jun 2021 19:36:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Linux-X64 -Xcomp.

This pull request has now been integrated.

Changeset: cfa6a995
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/cfa6a995e10ebce70c714b7060554d7411b8cf6f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269316: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Linux-X64 -Xcomp

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk17/pull/140

From dholmes at openjdk.java.net  Thu Jun 24 23:23:24 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 23:23:24 GMT
Subject: RFR: 8269003: Update the java manpage for JDK 18
Message-ID: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>

There are some start of release changes needed to the manpage that were overlooked:

- updated "removed options" section to get rid of things removed in 17 (nothing is removed in 18)
- update list of previous releases (corrected documentation title for JDK 13+)

The changes are easy to view in the nroff file so I didn't generate the html version.

Thanks,
David

-------------

Commit messages:
 - 8269003: Update the java manpage for JDK 18

Changes: https://git.openjdk.java.net/jdk/pull/4590/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4590&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269003
  Stats: 83 lines in 1 file changed: 3 ins; 75 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4590.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4590/head:pull/4590

PR: https://git.openjdk.java.net/jdk/pull/4590

From dholmes at openjdk.java.net  Thu Jun 24 23:44:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 23:44:07 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v2]
In-Reply-To: <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <1V-7sBwITCXofZpMc8jssx13954tpD_Agd5OP4DgR1w=.d26e93ca-2030-408e-978c-52b77c2a25de@github.com>
Message-ID: <N7duyDSOMLuJK-ndr536q-tNjh8NGSvrf9llpTwVBcQ=.31ce33c2-37a2-4f59-9683-92a5d747783f@github.com>

On Thu, 24 Jun 2021 00:22:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments according to reviewers's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 133:
> 
>> 131: // flush() is designated to flush out all pending messages. MT-safety is not provided. It is no-op if async logging is not in use.
>> 132: // In normal JVM termination, flush() is invoked in LogConfiguration::finalize(). When the users change logging configurations
>> 133: // via jcmd, LogConfiguration::configure_output() invokes it with the protection of ConfigurationLock.
> 
> Suggestion:
> // flush() ensures that all pending messages have been written out before it returns. It is not MT-safe
> // in itself. When users change the logging configuration via jcmd, LogConfiguration::configure_output()
> // calls flush() under the protection of the ConfigurationLock. In addition flush() is called during JVM
> // termination, via LogConfiguration::finalize, but that occurs during the VM termination safepoint and so
> // no calls to LogConfiguration::configure_output() can be active at the same time.

If you don't want to use my wording at least changed "designated" to "designed" as "designated is the wrong word. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From dholmes at openjdk.java.net  Thu Jun 24 23:44:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 23:44:11 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v2]
In-Reply-To: <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
Message-ID: <fsoyC80RHglPOSi0stCGUFUKypPQ4MfMq7b3JkwvlyY=.5c979939-765f-4fe2-8bb8-9966276dd128@github.com>

On Thu, 24 Jun 2021 05:58:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments according to reviewers's feedback.

src/hotspot/share/logging/logConfiguration.cpp line 272:

> 270: 
> 271:   // For async logging we have to ensure that all enqueued messages, which may refer to previous decorators,
> 272:   // or a soon-to-be-deleted outputs, are written out first. The flush() call ensures this.

s/outputs/output/

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From dholmes at openjdk.java.net  Thu Jun 24 23:48:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 23:48:03 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v2]
In-Reply-To: <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
Message-ID: <h1rBGyiKZwsR0dgiuAloVlema6vYV_uVN-gumMErBFs=.961ebf6e-465e-4f66-a5ca-ce533cb0bd9c@github.com>

On Thu, 24 Jun 2021 05:58:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments according to reviewers's feedback.

A couple of minor comment nits remain but otherwise this is fine.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/130

From dholmes at openjdk.java.net  Fri Jun 25 00:02:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 00:02:11 GMT
Subject: Integrated: 8268855: Cleanup name handling in the Thread class and
 subclasses
In-Reply-To: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
References: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
Message-ID: <QdwBhOU0rxVc-ZSS3of8iOlgDyo9-jlvmLvF6t0i6DY=.56cb5116-fad1-4cf9-b40d-af1dd6daddaf@github.com>

On Wed, 23 Jun 2021 06:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small cleanup item.
> 
> We can simplify and cleanup up name() management:
> 
> - make name() return "const char *" and only cast away constness at API boundaries when essential
> - add type_name() so that we can avoid code like "if (t->is_VM_Thread()) print("VMThread");
> - Rename JavaThread::get_thread_name() to name() (no need for the extra indirection)
> 
> There are a couple of minor changes to the appearance of some internal threads in the hs_err log e.g.
> 
>   0x000055af03e5b1b0 WatcherThread [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> is now:
> 
>   0x000055af03e5b1b0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> but this shouldn't affect anything and makes things more consistent.
> 
> Notes: 
> 
> 1. While "override" is the ideal style when declaring overriding methods it has to be applied to all virtual methods in a class. So unless "override" is already used in a class, I did not start using it. I have filed a separate RFE to convert the Thread classes to use "override" consistently.
> 2.  While there is no need to redeclare a virtual method as "virtual" I kept to the existing style in those classes where changes were made.
> 3. I did not override type_name() for all the JavaThread subclasses as it seemed unnecessary, but happy to hear other views on this.
> 
> Testing (in progress):
>  - All builds in tiers 1-5
>  - GHA
>  - tiers 1-3 as a sanity test
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 08ee7ae6
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08ee7ae67246b45be9684a4a283f0103f5f1c0c4
Stats:     85 lines in 16 files changed: 34 ins; 14 del; 37 mod

8268855: Cleanup name handling in the Thread class and subclasses

Reviewed-by: lfoltan, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/4569

From dholmes at openjdk.java.net  Fri Jun 25 00:02:10 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 00:02:10 GMT
Subject: RFR: 8268855: Cleanup name handling in the Thread class and
 subclasses
In-Reply-To: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
References: <HcnkH0nFHKGQMoq3qj_jahyn6E4qxMFAR272C4z-DLQ=.7ea40e9d-3911-4ceb-a8bb-05d64e08bf85@github.com>
Message-ID: <ZOAnUcLZzJ_jZAEpeG5j3Xfoep3xBBAGe-N0OQMlPE4=.358648ad-194a-41f1-bb90-ea07e4ec4c67@github.com>

On Wed, 23 Jun 2021 06:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small cleanup item.
> 
> We can simplify and cleanup up name() management:
> 
> - make name() return "const char *" and only cast away constness at API boundaries when essential
> - add type_name() so that we can avoid code like "if (t->is_VM_Thread()) print("VMThread");
> - Rename JavaThread::get_thread_name() to name() (no need for the extra indirection)
> 
> There are a couple of minor changes to the appearance of some internal threads in the hs_err log e.g.
> 
>   0x000055af03e5b1b0 WatcherThread [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> is now:
> 
>   0x000055af03e5b1b0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f685df00000,0x00007f685e000000] [id=15952]
> 
> but this shouldn't affect anything and makes things more consistent.
> 
> Notes: 
> 
> 1. While "override" is the ideal style when declaring overriding methods it has to be applied to all virtual methods in a class. So unless "override" is already used in a class, I did not start using it. I have filed a separate RFE to convert the Thread classes to use "override" consistently.
> 2.  While there is no need to redeclare a virtual method as "virtual" I kept to the existing style in those classes where changes were made.
> 3. I did not override type_name() for all the JavaThread subclasses as it seemed unnecessary, but happy to hear other views on this.
> 
> Testing (in progress):
>  - All builds in tiers 1-5
>  - GHA
>  - tiers 1-3 as a sanity test
> 
> Thanks,
> David

Thanks for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4569

From psandoz at openjdk.java.net  Fri Jun 25 00:24:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 00:24:03 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v2]
In-Reply-To: <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
Message-ID: <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>

On Thu, 24 Jun 2021 23:02:14 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use dll_locate_lib
>
> Unsure how this slipped through when we tested, but i think we need an explicit test. The test can execute a Java process with logging enabled and examine its log output (since the loading of SVML is logged). Searching the test code base should find some examples to copy.

> @PaulSandoz I have attempted to use dll_locate_lib. Please see if this looks ok to you.

Be useful if someone from hotspot-runtime can look, @dholmes-ora WDYT?

We still need to add a test.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From xliu at openjdk.java.net  Fri Jun 25 00:37:42 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 25 Jun 2021 00:37:42 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v2]
In-Reply-To: <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
Message-ID: <5JmTqyidv6zxVO_ZLzcFnKh_4KppFb0k5pt5LuW4MCY=.7f37e276-a088-4039-a6de-1abe8ba03b78@github.com>

On Thu, 24 Jun 2021 05:58:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments according to reviewers's feedback.

hi, @dcubed-ojdk 
Could you try to PR and see if it can solve the two crash sightings?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From xliu at openjdk.java.net  Fri Jun 25 00:37:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 25 Jun 2021 00:37:40 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v3]
In-Reply-To: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
Message-ID: <HeAWUXtJhhZ309W9bO9_MEi5uRiHCYNVJnRhIhN9va8=.965f9a3d-2a92-407d-bc32-e585878956b5@github.com>

> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
> is that previous flush() can't guarantee flush all pending messages in AsyncLog
> buffer. This patch implements flush() using a synchronizaton token and waits for
> completion. This approach isn't MT-safe but it can serialize all flush() calls in
> a thread. 
> 
> Two concurrent tests are appended to cover the hazard cases.
> This patch also comments LogConfiguration::configure_output() MT-safety.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Update a couple of comment nits.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/130/files
  - new: https://git.openjdk.java.net/jdk17/pull/130/files/b35073f7..3fc68f24

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/130/head:pull/130

PR: https://git.openjdk.java.net/jdk17/pull/130

From david.holmes at oracle.com  Fri Jun 25 01:05:59 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 25 Jun 2021 11:05:59 +1000
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v2]
In-Reply-To: <5JmTqyidv6zxVO_ZLzcFnKh_4KppFb0k5pt5LuW4MCY=.7f37e276-a088-4039-a6de-1abe8ba03b78@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <ywz68rET3z402L2g1VImEFmx2fyFyuhnomOlpaekIx4=.d81e922e-7e26-4850-83e7-34a598ca2ffc@github.com>
 <5JmTqyidv6zxVO_ZLzcFnKh_4KppFb0k5pt5LuW4MCY=.7f37e276-a088-4039-a6de-1abe8ba03b78@github.com>
Message-ID: <bec27f75-3939-defa-2e9d-e789ea1f690b@oracle.com>

On 25/06/2021 10:37 am, Xin Liu wrote:
> On Thu, 24 Jun 2021 05:58:54 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause
>>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>>> buffer. This patch implements flush() using a synchronizaton token and waits for
>>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>>> a thread.
>>>
>>> Two concurrent tests are appended to cover the hazard cases.
>>> This patch also comments LogConfiguration::configure_output() MT-safety.
>>
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update comments according to reviewers's feedback.
> 
> hi, @dcubed-ojdk
> Could you try to PR and see if it can solve the two crash sightings?

I already re-ran this through our tier 1-7 testing, running the gtests 
10 times in each configuration they normally run. No failures observed.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/130
> 

From dholmes at openjdk.java.net  Fri Jun 25 01:09:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 01:09:25 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads
Message-ID: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>

Please review this trivial cleanup to change Thread to JavaThread.

Testing (in progress):
  - tiers 1-3 sanity check
  - GHA

Thanks,
David

-------------

Commit messages:
 - 8269261: The PlaceHolder code uses Thread everywhere but is always dealing with JavaThreads

Changes: https://git.openjdk.java.net/jdk/pull/4592/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4592&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269261
  Stats: 20 lines in 2 files changed: 0 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4592.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4592/head:pull/4592

PR: https://git.openjdk.java.net/jdk/pull/4592

From minqi at openjdk.java.net  Fri Jun 25 01:15:29 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 25 Jun 2021 01:15:29 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v4]
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>

> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Remove 'Shared' from class names and rename corresponding files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4568/files
  - new: https://git.openjdk.java.net/jdk/pull/4568/files/438d54da..1c114bae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4568&range=02-03

  Stats: 85 lines in 8 files changed: 1 ins; 0 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4568/head:pull/4568

PR: https://git.openjdk.java.net/jdk/pull/4568

From xliu at openjdk.java.net  Fri Jun 25 01:22:23 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 25 Jun 2021 01:22:23 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v4]
In-Reply-To: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
Message-ID: <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>

> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
> is that previous flush() can't guarantee flush all pending messages in AsyncLog
> buffer. This patch implements flush() using a synchronizaton token and waits for
> completion. This approach isn't MT-safe but it can serialize all flush() calls in
> a thread. 
> 
> Two concurrent tests are appended to cover the hazard cases.
> This patch also comments LogConfiguration::configure_output() MT-safety.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Update comments part-2.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/130/files
  - new: https://git.openjdk.java.net/jdk17/pull/130/files/3fc68f24..eb520356

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=130&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/130/head:pull/130

PR: https://git.openjdk.java.net/jdk17/pull/130

From jiefu at openjdk.java.net  Fri Jun 25 01:31:03 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Jun 2021 01:31:03 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library
In-Reply-To: <k7vUyYCh3poBR67l6-j8D8cjC3EkJ7EA4nDaQic1PeA=.72a48a49-f3be-4f22-a685-1f6a06a8ec34@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <Ckw-D15UfaTGtxa1s5PTCBumzxntNdprVssEyL8CQoQ=.db69a54c-02fb-4de9-a404-47836ce3cf41@github.com>
 <8ARURDCx5zj_t0xeFHoElvk57v2DRN8g3S6Wmr-ksv0=.90be3f47-82c2-49f0-8f3f-5dc2177ccd4f@github.com>
 <k7vUyYCh3poBR67l6-j8D8cjC3EkJ7EA4nDaQic1PeA=.72a48a49-f3be-4f22-a685-1f6a06a8ec34@github.com>
Message-ID: <-mm4OgDdxi0tsOj3vSecGvj-O9U5sYt7jP_oVjImwCc=.073f34e6-b63c-4c71-b685-7ef981396549@github.com>

On Fri, 25 Jun 2021 00:09:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> @DamonFool The problem shows up only with the build on jdk.java.net. I also didn't see this problem while testing with internal builds.
>> 
>> So why it works for our internal builds but fails with the builds on jdk.java.net?
>
>> @DamonFool Very good question. It took me sometime to figure this out. There is something in java.exe which makes the difference. If you replace the java.exe in the internal build with the one on jdk.java.net you will be able to reproduce the problem. Giving the full path to dll_load in libjvm.so as in this patch fixes the issue.
> 
> I didn't get it tested on windows before.
> 
> Does the original code also work on Windows with your internal builds?
> If so, I think more investigation is needed to figure out the root cause.
> Thanks.

> @DamonFool The internal builds worked on both the platforms (Linux and Windows). Placing the built jvm.dll or libjvm.so with this patch in the jdk.java.net build also works on both the platforms.
> Please let me know if you have a better solution. This is the best that I could come up with. Please do keep in mind, we don't have too much time before RDP2.

I'm not sure if the change really fix the problem since the root cause still remains unknown.

Replacing the jvm.dll or libjvm.so makes very little sense to me.

A better way to verify the fix is re-building the whole image with the patch on Oracle's platform.
But that is still not enough.
Even though it gets passed on Oracle's machines, we still don't know if it really get fixed on all others' platforms.

I don't have a Windows machine so it's hard for me to investigate it.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From ccheung at openjdk.java.net  Fri Jun 25 02:17:04 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 25 Jun 2021 02:17:04 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads
In-Reply-To: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
Message-ID: <4p-kzErtMDCaVemmFrgtpgisbHxdggV6dtePCFnCN_U=.26d6d9d9-fd89-4d81-8d23-427cfe7e8980@github.com>

On Fri, 25 Jun 2021 01:00:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial cleanup to change Thread to JavaThread.
> 
> Testing (in progress):
>   - tiers 1-3 sanity check
>   - GHA
> 
> Thanks,
> David

Looks good. Just one nit.

src/hotspot/share/classfile/placeholders.hpp line 120:

> 118:   Symbol*           _supername;
> 119:   JavaThread*           _definer;       // owner of define token
> 120:   InstanceKlass*    _instanceKlass; // InstanceKlass from successful define

Can you align the underscore (_) and "//" with the line below?

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4592

From sviswanathan at openjdk.java.net  Fri Jun 25 02:26:36 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 02:26:36 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v3]
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <PnOx1-Uh4gSKUlyKCGksR2iDyhgurj78a0nRrM66mTs=.14f5b23f-4d7c-412d-8a5b-3dd7cd985f9b@github.com>

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Added test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/143/files
  - new: https://git.openjdk.java.net/jdk17/pull/143/files/cc59fb49..0eb647b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=01-02

  Stats: 76 lines in 1 file changed: 76 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/143/head:pull/143

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 02:26:37 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 02:26:37 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v3]
In-Reply-To: <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
 <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
Message-ID: <hZGlKDWcJZuLsrydhhTvboKckgADpUvnddpsub9UgiA=.df038999-0254-4b8c-b7c1-bfb8f6253a7c@github.com>

On Fri, 25 Jun 2021 00:21:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Unsure how this slipped through when we tested, but i think we need an explicit test. The test can execute a Java process with logging enabled and examine its log output (since the loading of SVML is logged). Searching the test code base should find some examples to copy.
>
>> @PaulSandoz I have attempted to use dll_locate_lib. Please see if this looks ok to you.
> 
> Be useful if someone from hotspot-runtime can look, @dholmes-ora WDYT?
> 
> We still need to add a test.

@PaulSandoz I have added a test. Please let me know if it looks ok.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 02:29:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 02:29:30 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v4]
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <GRh2bQQtQBShMC9RybJOK56yHXD3JbgC5qRQqOSAlTg=.2209b73a-9629-48ba-a640-52bd8f56f3e9@github.com>

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/143/files
  - new: https://git.openjdk.java.net/jdk17/pull/143/files/0eb647b0..bcc92eb3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/143/head:pull/143

PR: https://git.openjdk.java.net/jdk17/pull/143

From minqi at openjdk.java.net  Fri Jun 25 02:33:04 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 25 Jun 2021 02:33:04 GMT
Subject: RFR: 8269003: Update the java manpage for JDK 18
In-Reply-To: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
References: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
Message-ID: <kYZa90rUwhJRi62M8KyOoauihuxBeFa1rOwGWuG6PPw=.0945dfec-16c0-4a23-9da3-d1f06a40d5d9@github.com>

On Thu, 24 Jun 2021 23:12:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are some start of release changes needed to the manpage that were overlooked:
> 
> - updated "removed options" section to get rid of things removed in 17 (nothing is removed in 18)
> - update list of previous releases (corrected documentation title for JDK 13+)
> 
> The changes are easy to view in the nroff file so I didn't generate the html version.
> 
> Thanks,
> David

It seems for version 12 - 16 the http link is OK, but 17 is a 404. Is 17 URL different from others?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4590

From dholmes at openjdk.java.net  Fri Jun 25 02:36:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 02:36:04 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v4]
In-Reply-To: <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>
Message-ID: <9x8exKPg-vyetDHS1T8K70lcim8LD3XBIXXKtcejrz4=.c23031de-b6c7-48af-95f5-cdb3142041b7@github.com>

On Fri, 25 Jun 2021 01:22:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments part-2.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From sviswanathan at openjdk.java.net  Fri Jun 25 02:39:41 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 02:39:41 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  windows path

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/143/files
  - new: https://git.openjdk.java.net/jdk17/pull/143/files/bcc92eb3..113ef44c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=03-04

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/143/head:pull/143

PR: https://git.openjdk.java.net/jdk17/pull/143

From dholmes at openjdk.java.net  Fri Jun 25 02:40:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 02:40:41 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads [v2]
In-Reply-To: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
Message-ID: <B4tsEdbUDmqENjhYsx7oTF0PMFfpZos3y3qKrzfagFw=.055c9995-b27f-437f-87e8-99f4b3b9d426@github.com>

> Please review this trivial cleanup to change Thread to JavaThread.
> 
> Testing (in progress):
>   - tiers 1-3 sanity check
>   - GHA
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed alignment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4592/files
  - new: https://git.openjdk.java.net/jdk/pull/4592/files/42a54844..d84e386d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4592&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4592&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4592.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4592/head:pull/4592

PR: https://git.openjdk.java.net/jdk/pull/4592

From dholmes at openjdk.java.net  Fri Jun 25 02:40:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 02:40:45 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads [v2]
In-Reply-To: <4p-kzErtMDCaVemmFrgtpgisbHxdggV6dtePCFnCN_U=.26d6d9d9-fd89-4d81-8d23-427cfe7e8980@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
 <4p-kzErtMDCaVemmFrgtpgisbHxdggV6dtePCFnCN_U=.26d6d9d9-fd89-4d81-8d23-427cfe7e8980@github.com>
Message-ID: <rOEtgXz6GlvHKIAnkSTprr-claeibBeQJLVUv1wHiVw=.59a3d79e-81ba-4153-823a-268e7cd4ca7c@github.com>

On Fri, 25 Jun 2021 02:13:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed alignment
>
> src/hotspot/share/classfile/placeholders.hpp line 120:
> 
>> 118:   Symbol*           _supername;
>> 119:   JavaThread*           _definer;       // owner of define token
>> 120:   InstanceKlass*    _instanceKlass; // InstanceKlass from successful define
> 
> Can you align the underscore (_) and "//" with the line below?

Fixed.

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4592

From david.holmes at oracle.com  Fri Jun 25 02:41:44 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 25 Jun 2021 12:41:44 +1000
Subject: RFR: 8269003: Update the java manpage for JDK 18
In-Reply-To: <kYZa90rUwhJRi62M8KyOoauihuxBeFa1rOwGWuG6PPw=.0945dfec-16c0-4a23-9da3-d1f06a40d5d9@github.com>
References: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
 <kYZa90rUwhJRi62M8KyOoauihuxBeFa1rOwGWuG6PPw=.0945dfec-16c0-4a23-9da3-d1f06a40d5d9@github.com>
Message-ID: <2029da69-fa6b-292b-2367-2df1954ca6e5@oracle.com>

Hi Yumin,

Thanks for taking a look.

On 25/06/2021 12:33 pm, Yumin Qi wrote:
> On Thu, 24 Jun 2021 23:12:35 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> There are some start of release changes needed to the manpage that were overlooked:
>>
>> - updated "removed options" section to get rid of things removed in 17 (nothing is removed in 18)
>> - update list of previous releases (corrected documentation title for JDK 13+)
>>
>> The changes are easy to view in the nroff file so I didn't generate the html version.
>>
>> Thanks,
>> David
> 
> It seems for version 12 - 16 the http link is OK, but 17 is a 404. Is 17 URL different from others?

The JDK 17 link won't exist until 17 GA's in September.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4590
> 

From dholmes at openjdk.java.net  Fri Jun 25 02:52:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 02:52:05 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
 <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
Message-ID: <WS2QvawHHfuJCUZw6fMOQunrvyc846O0MRbZXZwjNBM=.3a144b60-8474-4321-a789-52fb9374eaa9@github.com>

On Fri, 25 Jun 2021 00:21:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Unsure how this slipped through when we tested, but i think we need an explicit test. The test can execute a Java process with logging enabled and examine its log output (since the loading of SVML is logged). Searching the test code base should find some examples to copy.
>
>> @PaulSandoz I have attempted to use dll_locate_lib. Please see if this looks ok to you.
> 
> Be useful if someone from hotspot-runtime can look, @dholmes-ora WDYT?
> 
> We still need to add a test.

@PaulSandoz I think we need input from the build team to determine why the java.net binary exhibits different behaviour to an internal build.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From jiefu at openjdk.java.net  Fri Jun 25 03:07:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Jun 2021 03:07:07 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
Message-ID: <ssdyXddCPZinwUyAuW4qXQniQaO0yx2ERTQvvTqX2Us=.603ffbf0-4f5a-4b22-97bb-40648a722d72@github.com>

On Fri, 25 Jun 2021 02:39:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows path

test/jdk/jdk/incubator/vector/LoadSvmlTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.

I think the copyright year should be 2021 only since it's a new file, right?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From minqi at openjdk.java.net  Fri Jun 25 03:16:09 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 25 Jun 2021 03:16:09 GMT
Subject: RFR: 8269003: Update the java manpage for JDK 18
In-Reply-To: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
References: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
Message-ID: <aATFWq4j2z-XO-dXqHeKZz86dhXz0JBfgJUfeNfApPI=.b912ca8e-d82c-4aef-ace0-9e6c80ab6e22@github.com>

On Thu, 24 Jun 2021 23:12:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are some start of release changes needed to the manpage that were overlooked:
> 
> - updated "removed options" section to get rid of things removed in 17 (nothing is removed in 18)
> - update list of previous releases (corrected documentation title for JDK 13+)
> 
> The changes are easy to view in the nroff file so I didn't generate the html version.
> 
> Thanks,
> David

Marked as reviewed by minqi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4590

From sviswanathan at openjdk.java.net  Fri Jun 25 03:19:01 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 03:19:01 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <ssdyXddCPZinwUyAuW4qXQniQaO0yx2ERTQvvTqX2Us=.603ffbf0-4f5a-4b22-97bb-40648a722d72@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
 <ssdyXddCPZinwUyAuW4qXQniQaO0yx2ERTQvvTqX2Us=.603ffbf0-4f5a-4b22-97bb-40648a722d72@github.com>
Message-ID: <K3lw0I1GPLXBThqkejrThJecYXYy3oO2ODrDgi4xMEs=.b1c6f898-9c80-41d8-b6a0-464ef816cb0c@github.com>

On Fri, 25 Jun 2021 03:04:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   windows path
>
> test/jdk/jdk/incubator/vector/LoadSvmlTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> I think the copyright year should be 2021 only since it's a new file, right?

Thanks for catching it. I will correct the copyright year.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From psandoz at openjdk.java.net  Fri Jun 25 03:19:00 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 03:19:00 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
 <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
Message-ID: <_GpZKnL2a2XhEM6K4iwah-Pchmfb9psiH7JF4CctXIY=.f22e34b7-d1de-4290-aa59-8100ac68a09d@github.com>

On Fri, 25 Jun 2021 00:21:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Unsure how this slipped through when we tested, but i think we need an explicit test. The test can execute a Java process with logging enabled and examine its log output (since the loading of SVML is logged). Searching the test code base should find some examples to copy.
>
>> @PaulSandoz I have attempted to use dll_locate_lib. Please see if this looks ok to you.
> 
> Be useful if someone from hotspot-runtime can look, @dholmes-ora WDYT?
> 
> We still need to add a test.

> @PaulSandoz I have added a test. Please let me know if it looks ok.

Test looks good. I will run through our build/test system tomorrow morning, and try to get some details on build differences.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From psandoz at openjdk.java.net  Fri Jun 25 03:19:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 03:19:03 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
Message-ID: <5mira0AEa_cpzwlJ2e0gLZnpN343ou3eHvKtRh4XmyM=.af2562ad-0035-46e6-9e1b-30f2708ce543@github.com>

On Fri, 25 Jun 2021 02:39:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows path

test/jdk/jdk/incubator/vector/LoadSvmlTest.java line 67:

> 65:             "-Xmn8m", "-Xlog:library=info",
> 66:             "--add-modules=jdk.incubator.vector",
> 67:             "LoadSvmlTest$VectorTest");

Can you do `VectorTest.class.getName()` instead?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 03:22:59 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 03:22:59 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
Message-ID: <Al6dX9bb4qa_5JT_2Oe9b_qQBE1B3f0FcVvJlu_vO-I=.0aefd276-1544-4173-b22f-169fc81c502f@github.com>

On Fri, 25 Jun 2021 02:39:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows path

Thanks a lot Paul.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From dholmes at openjdk.java.net  Fri Jun 25 04:23:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 04:23:01 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
Message-ID: <mKuQ4dOG_5QFT4tvIGlulFc2fQ_SINzAzNBxCauHAQ8=.bcf35900-1762-48c4-9a61-85880e300b68@github.com>

On Fri, 25 Jun 2021 02:39:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows path

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7009:

> 7007: #else
> 7008:     int ret = jio_snprintf(dll_path, sizeof(dll_path), "%s%slib", Arguments::get_java_home(), os::file_separator());
> 7009: #endif

There is a platform independent way to do this. Here is the example of how libverify is loaded by the JVM:

// Load verify dll
  char buffer[JVM_MAXPATHLEN];
  char ebuf[1024];
  if (!os::dll_locate_lib(buffer, sizeof(buffer), Arguments::get_dll_dir(), "verify"))
    return NULL; // Caller will throw VerifyError

  void *lib_handle = os::dll_load(buffer, ebuf, sizeof(ebuf));

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 04:38:28 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 04:38:28 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v6]
In-Reply-To: <WS2QvawHHfuJCUZw6fMOQunrvyc846O0MRbZXZwjNBM=.3a144b60-8474-4321-a789-52fb9374eaa9@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
 <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
 <WS2QvawHHfuJCUZw6fMOQunrvyc846O0MRbZXZwjNBM=.3a144b60-8474-4321-a789-52fb9374eaa9@github.com>
Message-ID: <LL0KQxXKse7J94N5SJWSgz7GoexINCnFWEUC4l8_TcU=.f32ffc40-8b2d-418b-bf20-6f5203dfe1d0@github.com>

On Fri, 25 Jun 2021 02:49:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> @PaulSandoz I have attempted to use dll_locate_lib. Please see if this looks ok to you.
>> 
>> Be useful if someone from hotspot-runtime can look, @dholmes-ora WDYT?
>> 
>> We still need to add a test.
>
> @PaulSandoz I think we need input from the build team to determine why the java.net binary exhibits different behaviour to an internal build.

@dholmes-ora Thanks a lot. I have updated the patch accordingly.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 04:38:27 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 04:38:27 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v6]
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <pTIYJXibYwzlbKbqi4q5kJgFzqLz7eIq0TjM2vTn_eY=.a0fbf563-5af1-4056-b311-ce239919e9ef@github.com>

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Implement review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/143/files
  - new: https://git.openjdk.java.net/jdk17/pull/143/files/113ef44c..7fe81154

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=04-05

  Stats: 14 lines in 2 files changed: 0 ins; 8 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/143/head:pull/143

PR: https://git.openjdk.java.net/jdk17/pull/143

From dholmes at openjdk.java.net  Fri Jun 25 04:38:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 04:38:29 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v5]
In-Reply-To: <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <b6qPWmUyzYEBOTGFPmxYZM1xVY3Tt4LBR-Qx0N6HVYc=.bffe37c4-3e16-4af7-b2c5-4b8f415e5bf2@github.com>
Message-ID: <K0U_2wA44u-j0CjLyFyFMXiqegtDeK4coX_2ZAszqY8=.e5ba6318-0a40-4550-a21d-babdfd2c5e5f@github.com>

On Fri, 25 Jun 2021 02:39:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows path

I've checked the layout of the jdk.java.net binaries and those we use in our internal testing and see no difference, so I cannot explain why one case would fail when the other succeeds.

I'll take the latest patch for a spin through our build/test system and pass the link to @PaulSandoz to check progress/success.

David

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From dholmes at openjdk.java.net  Fri Jun 25 04:46:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 04:46:04 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v6]
In-Reply-To: <pTIYJXibYwzlbKbqi4q5kJgFzqLz7eIq0TjM2vTn_eY=.a0fbf563-5af1-4056-b311-ce239919e9ef@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <pTIYJXibYwzlbKbqi4q5kJgFzqLz7eIq0TjM2vTn_eY=.a0fbf563-5af1-4056-b311-ce239919e9ef@github.com>
Message-ID: <BZtO1bkK23gcbmjpT_BP_Hxd9kwifNGAhku8fmKNedA=.a0336453-c253-40da-87e0-6db5c8d3b6c0@github.com>

On Fri, 25 Jun 2021 04:38:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review comments

test/jdk/jdk/incubator/vector/LoadSvmlTest.java line 74:

> 72:           output.shouldMatch("Loaded library .*svml.dll");
> 73:         else
> 74:           output.shouldMatch("Loaded library .*libsvml.so");

You could just check for .*svml.* and not worry about dll vs so. That should suffice and keeps the test simpler.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 04:55:40 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 04:55:40 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v7]
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <Awd3rDGzKVpi7sqATUUFoF6sCKiT-Ob3Mzc90bIdD9c=.1885cd38-b3da-4aab-b098-b9a996b55086@github.com>

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  simplify test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/143/files
  - new: https://git.openjdk.java.net/jdk17/pull/143/files/7fe81154..2e127c81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=05-06

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/143/head:pull/143

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 04:55:43 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 04:55:43 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v6]
In-Reply-To: <BZtO1bkK23gcbmjpT_BP_Hxd9kwifNGAhku8fmKNedA=.a0336453-c253-40da-87e0-6db5c8d3b6c0@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <pTIYJXibYwzlbKbqi4q5kJgFzqLz7eIq0TjM2vTn_eY=.a0fbf563-5af1-4056-b311-ce239919e9ef@github.com>
 <BZtO1bkK23gcbmjpT_BP_Hxd9kwifNGAhku8fmKNedA=.a0336453-c253-40da-87e0-6db5c8d3b6c0@github.com>
Message-ID: <Fr4o00RYbe7J8vtF7pJpRL3H9AjQY4_s6yDtmG87ayU=.6245f138-3743-494f-8d44-d5648dbaeed8@github.com>

On Fri, 25 Jun 2021 04:43:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review comments
>
> test/jdk/jdk/incubator/vector/LoadSvmlTest.java line 74:
> 
>> 72:           output.shouldMatch("Loaded library .*svml.dll");
>> 73:         else
>> 74:           output.shouldMatch("Loaded library .*libsvml.so");
> 
> You could just check for .*svml.* and not worry about dll vs so. That should suffice and keeps the test simpler.

Updated the test accordingly. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From stuefe at openjdk.java.net  Fri Jun 25 05:37:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 05:37:03 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <An16hOY2P8rV5keHrGk6bxMBROBE8hP5MK0hp1wK61w=.c449257b-2bf5-4048-b99f-fa85256c861e@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

Hi,

I created the CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345

When you have time, please take a look. Thank you.

..Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Fri Jun 25 06:03:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 06:03:07 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
Message-ID: <0U_Ii4mfxbkFrc8kbWtN8uEaaN6SX8WnPWqNhcv-O0g=.518601c8-81ff-4d06-ad13-f26d2c71d3f2@github.com>

On Mon, 21 Jun 2021 08:25:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback Severin; renamed query function
>
> src/hotspot/os/linux/os_linux.cpp line 2142:
> 
>> 2140: bool os::Linux::query_process_memory_info(os::Linux::meminfo_t* info) {
>> 2141:   FILE* f = ::fopen("/proc/self/status", "r");
>> 2142:   const int num_values = 8;
> 
> Refactoring of `os::Linux::print_process_memory_info` looks good. But now that you've already created `os::Linux::meminfo_t` anyway I'd suggest to make `num_values == sizeof(os::Linux::meminfo_t)/sizeof(ssize_t)`.

Okay, makes sense. I was a bit apprehensive since that relies on the internal layout of this structure. But OTOH if that number is wrong, the worst that happens is that we, each time, parse through the whole of /proc/self/status instead of stopping early when all data are found. Which may happen anyway since not all kernels support all of these data.

> src/hotspot/share/services/diagnosticCommand.cpp line 99:
> 
>> 97:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapInfoDCmd>(full_export, true, false));
>> 98:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<FinalizerInfoDCmd>(full_export, true, false));
>> 99:   LINUX_ONLY(DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));)
> 
> Not sure if the commands are really sorted and if order is important here. Otherwise you could add the new command a few lines later where there already exists an `#ifdef LINUX` section:
> 
> 
> #ifdef LINUX
>   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<PerfMapDCmd>(full_export, true, false));
>   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));
> #endif // LINUX

I don't think order matters, and grouping linux specific commands looks better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Fri Jun 25 06:22:37 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 06:22:37 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v3]
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>

> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
> 
> 
> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
> 
> If this finds agreement, I will file a CSR.
> 
> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                    ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                    ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Volker feedback
 - Merge
 - Feedback Severin; renamed query function
 - start

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4510/files
  - new: https://git.openjdk.java.net/jdk/pull/4510/files/a48791e4..29807b26

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=01-02

  Stats: 28324 lines in 497 files changed: 16225 ins; 10712 del; 1387 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510

PR: https://git.openjdk.java.net/jdk/pull/4510

From lzang at openjdk.java.net  Fri Jun 25 08:05:11 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 25 Jun 2021 08:05:11 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v27]
In-Reply-To: <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
Message-ID: <NnEymx3Sa1D7rsIbSRemj40FD_cFZnstaFIp2X7ZXzs=.ed90a175-0575-4653-ba98-be41068441b1@github.com>

On Mon, 7 Jun 2021 07:58:26 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - fix build issue after rebase and fix one issue
>  - Merge branch 'master'
>  - Merge branch 'master' into pd
>  - update copyright info
>  - Merge branch 'master' into par-dump
>  - undo JMap.java
>  - code refine and typo fix
>  - Merge branch 'master' into par-dump
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/908aca29...78c2c763

Dear All? Sorry for not updating this PR for quite a while. I will try to add detailed explaination of the implementation here to make it easier to be reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From myano at openjdk.java.net  Fri Jun 25 12:24:20 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 25 Jun 2021 12:24:20 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized
 Windows platform
Message-ID: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>

Hi all,

Could you please review the 8269373 bug fixes?

These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

-------------

Commit messages:
 - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

Changes: https://git.openjdk.java.net/jdk/pull/4594/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269373
  Stats: 14 lines in 6 files changed: 5 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4594.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594

PR: https://git.openjdk.java.net/jdk/pull/4594

From psandoz at openjdk.java.net  Fri Jun 25 15:07:06 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 15:07:06 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v7]
In-Reply-To: <Awd3rDGzKVpi7sqATUUFoF6sCKiT-Ob3Mzc90bIdD9c=.1885cd38-b3da-4aab-b098-b9a996b55086@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <Awd3rDGzKVpi7sqATUUFoF6sCKiT-Ob3Mzc90bIdD9c=.1885cd38-b3da-4aab-b098-b9a996b55086@github.com>
Message-ID: <37RrKEFeiB3-vJ_T8XsFCtv1o4KtJmi_Ff9oDbq-Aj0=.4ae94614-ef90-4f32-bc25-25fc7d3879c9@github.com>

On Fri, 25 Jun 2021 04:55:40 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify test

All tests pass. I will talk with the build folks to find a root cause but i am confident it's more robust due to the use of `os::dll_locate_lib`.

If you can please update the test to use the class name, rather explicitly using the result of that.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/143

From simonis at openjdk.java.net  Fri Jun 25 15:38:10 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 25 Jun 2021 15:38:10 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v3]
In-Reply-To: <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>
Message-ID: <MMg7ESm1GxsonnlkARTPdMdhHoF1NfvTavWZ-I4bAuc=.0d2544b4-d8e7-48f1-b0fc-5ca1a57330a3@github.com>

On Fri, 25 Jun 2021 06:22:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Volker feedback
>  - Merge
>  - Feedback Severin; renamed query function
>  - start

Thanks for the cleanups. Looks good to me now.

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Fri Jun 25 16:18:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 16:18:03 GMT
Subject: RFR: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
In-Reply-To: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
References: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
Message-ID: <KcQiytuzs5ShqwyqBXWr60i2b2ZtAXTvwIsUB83BTos=.c6cbcd73-e2a7-4cdd-b09f-1e5e4fed687f@github.com>

On Fri, 14 May 2021 06:18:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For JDK-8185734: "[Windows] Structured Exception Catcher missing around gtest execution", I specified that `--gtest_catch_exceptions=0` should be specified when starting the gtestlauncher from within the gtest jtreg wrappers. The intent was to leave signal handling to the VM - needed is this for windows 32-bit where fault handling happens via stack-based SEH, and gtestrunner's own SEH handler would intercept exceptions bubbling up from faults in test coding. For more details, please see the description of JDK-8185734.
> 
> However turned out I added a typo. It did not prevent the option from working, but should be fixed nevertheless.
> 
> This is really really trivial. Thanks for reviewing.

Gentle ping. May I please have a review? This is really trivial. Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4025

From shade at openjdk.java.net  Fri Jun 25 16:27:59 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 25 Jun 2021 16:27:59 GMT
Subject: RFR: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
In-Reply-To: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
References: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
Message-ID: <p_DFMESM64HKPWNCWdWsmr3vMOX42B320ofIM8OT8PQ=.ae26689e-b909-4c05-882d-e34969b21ddc@github.com>

On Fri, 14 May 2021 06:18:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For JDK-8185734: "[Windows] Structured Exception Catcher missing around gtest execution", I specified that `--gtest_catch_exceptions=0` should be specified when starting the gtestlauncher from within the gtest jtreg wrappers. The intent was to leave signal handling to the VM - needed is this for windows 32-bit where fault handling happens via stack-based SEH, and gtestrunner's own SEH handler would intercept exceptions bubbling up from faults in test coding. For more details, please see the description of JDK-8185734.
> 
> However turned out I added a typo. It did not prevent the option from working, but should be fixed nevertheless.
> 
> This is really really trivial. Thanks for reviewing.

Yes, looks pretty trivial to me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4025

From shade at openjdk.java.net  Fri Jun 25 16:37:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 25 Jun 2021 16:37:08 GMT
Subject: RFR: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
In-Reply-To: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
References: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
Message-ID: <yAHJVdD3VcYfS0JD5uzAnJQob8VL1QWIh9ZQACfg_Q8=.ab6c01bc-7079-44a1-9a9a-7c252e3311d1@github.com>

On Fri, 14 May 2021 06:18:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For JDK-8185734: "[Windows] Structured Exception Catcher missing around gtest execution", I specified that `--gtest_catch_exceptions=0` should be specified when starting the gtestlauncher from within the gtest jtreg wrappers. The intent was to leave signal handling to the VM - needed is this for windows 32-bit where fault handling happens via stack-based SEH, and gtestrunner's own SEH handler would intercept exceptions bubbling up from faults in test coding. For more details, please see the description of JDK-8185734.
> 
> However turned out I added a typo. It did not prevent the option from working, but should be fixed nevertheless.
> 
> This is really really trivial. Thanks for reviewing.

One thing, shouldn't that be in JDK 17?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4025

From stuefe at openjdk.java.net  Fri Jun 25 16:37:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 16:37:07 GMT
Subject: RFR: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
In-Reply-To: <p_DFMESM64HKPWNCWdWsmr3vMOX42B320ofIM8OT8PQ=.ae26689e-b909-4c05-882d-e34969b21ddc@github.com>
References: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
 <p_DFMESM64HKPWNCWdWsmr3vMOX42B320ofIM8OT8PQ=.ae26689e-b909-4c05-882d-e34969b21ddc@github.com>
Message-ID: <-daWvh0k89hjh3ItPu4pBHIZsHAurSMZRYWCTelLDCg=.a9cfbe33-0121-4e12-beac-f3d7da50800a@github.com>

On Fri, 25 Jun 2021 16:25:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Yes, looks pretty trivial to me.

Thanks Aleksey!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4025

From stuefe at openjdk.java.net  Fri Jun 25 16:37:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 16:37:08 GMT
Subject: Integrated: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
In-Reply-To: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
References: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
Message-ID: <-cDA-Nl4D2xIAjqqAptT4-mu0tzlxCvJLixzk-rLO14=.e4963573-b052-461c-a439-608f05021c54@github.com>

On Fri, 14 May 2021 06:18:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For JDK-8185734: "[Windows] Structured Exception Catcher missing around gtest execution", I specified that `--gtest_catch_exceptions=0` should be specified when starting the gtestlauncher from within the gtest jtreg wrappers. The intent was to leave signal handling to the VM - needed is this for windows 32-bit where fault handling happens via stack-based SEH, and gtestrunner's own SEH handler would intercept exceptions bubbling up from faults in test coding. For more details, please see the description of JDK-8185734.
> 
> However turned out I added a typo. It did not prevent the option from working, but should be fixed nevertheless.
> 
> This is really really trivial. Thanks for reviewing.

This pull request has now been integrated.

Changeset: b565459f
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b565459f83b749a01d7d873a01bb7dbdf55745de
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8267138: Stray suffix when starting gtests via GTestWrapper.java

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/4025

From coleenp at openjdk.java.net  Fri Jun 25 16:39:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 25 Jun 2021 16:39:07 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 handshake
In-Reply-To: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
References: <_CJ5tqp1Sjb2hOQ39b0rqCZF8HckIpbfhxLL0gyLY3g=.6917cb18-ca06-4bf6-ab1c-21ef9d61a487@github.com>
Message-ID: <TY6Tzlkx6Gi1wo3AzvVjYUIa5E9InjlczHaqVSS6Rpg=.42a8ccef-1c1f-4fcc-aa32-5b2e752f4207@github.com>

On Wed, 16 Jun 2021 16:03:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.
> In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for handshakes.
> 
> Tested with tier1-6.

Things got conflated in this PR.  The test is here:

bool HandshakeState::suspend_with_handshake() {
  if (_handshakee->is_exiting() ||
     _handshakee->threadObj() == NULL) {
    log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " exiting", p2i(_handshakee));
    return false;
  }

We get the JavaThread from threadObj then call java_suspend, so it can't be NULL!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4512

From ccheung at openjdk.java.net  Fri Jun 25 16:54:06 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 25 Jun 2021 16:54:06 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v4]
In-Reply-To: <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
Message-ID: <W7LSAfOiaaNbh5bUJQB1z9C1sge_2kuMcsgPjdkwxz8=.d070d12a-9147-4a9f-af38-bb304d3ba442@github.com>

On Fri, 25 Jun 2021 01:15:29 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>> 
>> Tests: tier1,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 'Shared' from class names and rename corresponding files

Latest changes look good. One question.

src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 28:

> 26: #define SHARED_CDS_LAMBDAPROXYCLASSINFO_HPP
> 27: #include "cds/metaspaceShared.hpp"
> 28: #include "classfile/javaClasses.hpp"

Is this include necessary?

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4568

From coleenp at openjdk.java.net  Fri Jun 25 17:57:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 25 Jun 2021 17:57:20 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in suspend
 handshake
Message-ID: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>

In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.
Tested already with tier1-6 (rerun tier1).

-------------

Commit messages:
 - 8268902: Testing for threadObj != NULL is unnecessary in suspend handshake

Changes: https://git.openjdk.java.net/jdk/pull/4598/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4598&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268902
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4598.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4598/head:pull/4598

PR: https://git.openjdk.java.net/jdk/pull/4598

From sviswanathan at openjdk.java.net  Fri Jun 25 18:26:38 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 18:26:38 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v8]
In-Reply-To: <_GpZKnL2a2XhEM6K4iwah-Pchmfb9psiH7JF4CctXIY=.f22e34b7-d1de-4290-aa59-8100ac68a09d@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <0qYPY6MRqMpCII2dk0BfEzulhpkCVV30iaSAr-btpaA=.9ba6a423-ecaa-430e-9db7-f617e3bd4645@github.com>
 <6FePv5fprUmiEUE7v9PBwXjUfO87DDFvvyjHRy6xX68=.682aaa26-bf63-42f4-8057-d4f9579d61b8@github.com>
 <_GpZKnL2a2XhEM6K4iwah-Pchmfb9psiH7JF4CctXIY=.f22e34b7-d1de-4290-aa59-8100ac68a09d@github.com>
Message-ID: <yLvo8WApmc1FUMt0jZrUfwptMP4QieCw378sO5hzpnw=.127febf4-1062-4b46-943e-6bcb78b93b91@github.com>

On Fri, 25 Jun 2021 03:15:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> @PaulSandoz I have attempted to use dll_locate_lib. Please see if this looks ok to you.
>> 
>> Be useful if someone from hotspot-runtime can look, @dholmes-ora WDYT?
>> 
>> We still need to add a test.
>
>> @PaulSandoz I have added a test. Please let me know if it looks ok.
> 
> Test looks good. I will run through our build/test system tomorrow morning, and try to get some details on build differences.

@PaulSandoz I have updated the test to use VectorTest.class.getName(). Please let me know if I can integrate.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 18:26:36 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 18:26:36 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v8]
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <ggzHsQpGRNyhbHV5_SVPAXfL35W6KqYEKbGE3VM86bA=.6b61a7ad-aa02-4b72-8e84-8d13b67013a4@github.com>

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Use class.getName

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/143/files
  - new: https://git.openjdk.java.net/jdk17/pull/143/files/2e127c81..d5420ed9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=143&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/143/head:pull/143

PR: https://git.openjdk.java.net/jdk17/pull/143

From psandoz at openjdk.java.net  Fri Jun 25 18:30:02 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 18:30:02 GMT
Subject: [jdk17] RFR: 8269335: Unable to load svml library [v8]
In-Reply-To: <ggzHsQpGRNyhbHV5_SVPAXfL35W6KqYEKbGE3VM86bA=.6b61a7ad-aa02-4b72-8e84-8d13b67013a4@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
 <ggzHsQpGRNyhbHV5_SVPAXfL35W6KqYEKbGE3VM86bA=.6b61a7ad-aa02-4b72-8e84-8d13b67013a4@github.com>
Message-ID: <FsstJ_lSwDhaBJh2fBPjmL1HzTGDvsynoVT8eLflFYM=.07bb27b3-c5c6-43e1-888a-53138acefa65@github.com>

On Fri, 25 Jun 2021 18:26:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
>> We need to give full svml library path to dll_load call for the load to succeed.,
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use class.getName

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/143

From sviswanathan at openjdk.java.net  Fri Jun 25 18:35:12 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 18:35:12 GMT
Subject: [jdk17] Integrated: 8269335: Unable to load svml library
In-Reply-To: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
References: <0OvZZt622mfi3Bpqj9GaWIh7nE7Sb1l2Tgpj-JEoQq4=.0aa06b64-bb33-48cd-8822-7fe048d3adf3@github.com>
Message-ID: <oJW0_kXk_jBr86ZljmEPhe_38VfGhq7MRMw1v24CZRw=.168eaac7-cb5a-4dbd-9a5f-c5672e1c4bac@github.com>

On Thu, 24 Jun 2021 21:05:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> The OpenJDK 17 early access build from jdk.java.net fails to load svml library. 
> We need to give full svml library path to dll_load call for the load to succeed.,

This pull request has now been integrated.

Changeset: 1e3b418a
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/1e3b418a53a080a53827989393362338b43dd363
Stats:     77 lines in 2 files changed: 76 ins; 0 del; 1 mod

8269335: Unable to load svml library

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk17/pull/143

From coleenp at openjdk.java.net  Fri Jun 25 20:37:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 25 Jun 2021 20:37:08 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads [v2]
In-Reply-To: <B4tsEdbUDmqENjhYsx7oTF0PMFfpZos3y3qKrzfagFw=.055c9995-b27f-437f-87e8-99f4b3b9d426@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
 <B4tsEdbUDmqENjhYsx7oTF0PMFfpZos3y3qKrzfagFw=.055c9995-b27f-437f-87e8-99f4b3b9d426@github.com>
Message-ID: <BGZ10NN2AkwegE9avaPm8M7eM3DRZ5rj7a75RBX_unU=.2d7248c9-a7b0-492a-91d2-b8f761a4f472@github.com>

On Fri, 25 Jun 2021 02:40:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this trivial cleanup to change Thread to JavaThread.
>> 
>> Testing (in progress):
>>   - tiers 1-3 sanity check
>>   - GHA
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed alignment

Looks good!

src/hotspot/share/classfile/placeholders.cpp line 56:

> 54:    }
> 55:    JavaThread* thread()                const { return _thread;}
> 56:    void set_thread(JavaThread* thread) { _thread = thread; }

Can you line these { up also?

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4592

From pchilanomate at openjdk.java.net  Fri Jun 25 20:57:04 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 25 Jun 2021 20:57:04 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
Message-ID: <1p5iIqBmdMXuAgQ1Ge0Vi_K60vWfChcDXc2-2mvHtQQ=.bbd216c6-6494-42e9-957a-da11b4017fc3@github.com>

On Fri, 25 Jun 2021 17:50:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.
> Tested already with tier1-6 (rerun tier1).

LGTM.

-------------

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4598

From dcubed at openjdk.java.net  Fri Jun 25 21:11:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 25 Jun 2021 21:11:05 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
Message-ID: <uY6ta67i9UlcbP7u5LAK-3oh4WThgUmnlynWG-ymxWc=.9c29c728-961a-4c31-9b8d-87a70888fa83@github.com>

On Fri, 25 Jun 2021 17:50:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.
> Tested already with tier1-6 (rerun tier1).

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4598

From coleenp at openjdk.java.net  Fri Jun 25 22:31:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 25 Jun 2021 22:31:59 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
Message-ID: <kgjRNz9dQ1_Skr68ocnx2Bm2gNF3Eae4-n0gN-NaY0M=.3d95bbbc-93d5-4cfc-80b1-5592b42b0ebf@github.com>

On Fri, 25 Jun 2021 17:50:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.
> Tested already with tier1-6 (rerun tier1).

Thanks Patricio and Dan. Patricio thank you for the offline discussion and sanity check :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4598

From minqi at openjdk.java.net  Fri Jun 25 22:32:03 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 25 Jun 2021 22:32:03 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v4]
In-Reply-To: <W7LSAfOiaaNbh5bUJQB1z9C1sge_2kuMcsgPjdkwxz8=.d070d12a-9147-4a9f-af38-bb304d3ba442@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
 <W7LSAfOiaaNbh5bUJQB1z9C1sge_2kuMcsgPjdkwxz8=.d070d12a-9147-4a9f-af38-bb304d3ba442@github.com>
Message-ID: <DZQoDoJXzYJsmlxsxkzm8PeVf2uUArknBISid3XKeZg=.76bb164e-5eef-4638-a8f1-7baf9e3438aa@github.com>

On Fri, 25 Jun 2021 16:50:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove 'Shared' from class names and rename corresponding files
>
> src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 28:
> 
>> 26: #define SHARED_CDS_LAMBDAPROXYCLASSINFO_HPP
>> 27: #include "cds/metaspaceShared.hpp"
>> 28: #include "classfile/javaClasses.hpp"
> 
> Is this include necessary?

It is needed, line 84:
 return java_lang_String::hash_code((const jbyte*)sym->bytes(), sym->utf8_length());

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From david.holmes at oracle.com  Fri Jun 25 22:43:10 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 26 Jun 2021 08:43:10 +1000
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
Message-ID: <10e8ad8d-ae28-9ce3-3725-1904567c181e@oracle.com>

On 26/06/2021 3:57 am, Coleen Phillimore wrote:
> In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.

This is probably true, but possibly only because we screen out 
jni-attaching threads at a higher-level.

Cheers,
David

> Tested already with tier1-6 (rerun tier1).
> 
> -------------
> 
> Commit messages:
>   - 8268902: Testing for threadObj != NULL is unnecessary in suspend handshake
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4598/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4598&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8268902
>    Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4598.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4598/head:pull/4598
> 
> PR: https://git.openjdk.java.net/jdk/pull/4598
> 

From ccheung at openjdk.java.net  Fri Jun 25 23:39:13 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 25 Jun 2021 23:39:13 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v4]
In-Reply-To: <DZQoDoJXzYJsmlxsxkzm8PeVf2uUArknBISid3XKeZg=.76bb164e-5eef-4638-a8f1-7baf9e3438aa@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
 <W7LSAfOiaaNbh5bUJQB1z9C1sge_2kuMcsgPjdkwxz8=.d070d12a-9147-4a9f-af38-bb304d3ba442@github.com>
 <DZQoDoJXzYJsmlxsxkzm8PeVf2uUArknBISid3XKeZg=.76bb164e-5eef-4638-a8f1-7baf9e3438aa@github.com>
Message-ID: <zH2Gs0xQUqkzEM7Js3PJ-sWRHWZdmn97OHyHb9dxwJI=.7d3b47c1-0533-4a98-a075-054948c062af@github.com>

On Fri, 25 Jun 2021 22:28:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 28:
>> 
>>> 26: #define SHARED_CDS_LAMBDAPROXYCLASSINFO_HPP
>>> 27: #include "cds/metaspaceShared.hpp"
>>> 28: #include "classfile/javaClasses.hpp"
>> 
>> Is this include necessary?
>
> It is needed, line 84:
>  return java_lang_String::hash_code((const jbyte*)sym->bytes(), sym->utf8_length());

I see.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From dlong at openjdk.java.net  Sat Jun 26 00:28:14 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 26 Jun 2021 00:28:14 GMT
Subject: [jdk17] RFR: 8258746: illegal access to global field
 _jvmci_old_thread_counters by terminated thread causes crash
Message-ID: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>

This change moves the access to the global field _jvmci_old_thread_counters from the thread destructor to JavaThread::exit().  See the JBS issue for more details.  The free of _jvmci_counters is left in the destructor intentionally, as it is allocated in the JavaThread constructor and not all termination paths go through JavaThread::exit().

-------------

Commit messages:
 - move access to global from thread destructor to exit()

Changes: https://git.openjdk.java.net/jdk17/pull/154/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=154&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258746
  Stats: 16 lines in 1 file changed: 11 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/154.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/154/head:pull/154

PR: https://git.openjdk.java.net/jdk17/pull/154

From stuefe at openjdk.java.net  Sat Jun 26 05:41:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 26 Jun 2021 05:41:03 GMT
Subject: RFR: JDK-8267138: Stray suffix when starting gtests via
 GTestWrapper.java
In-Reply-To: <yAHJVdD3VcYfS0JD5uzAnJQob8VL1QWIh9ZQACfg_Q8=.ab6c01bc-7079-44a1-9a9a-7c252e3311d1@github.com>
References: <-4yJsMEIkLtCmB0uvTuLaaYLHhtBwoz2KIuQIHyvaDw=.6ca2c6b6-f324-4623-8860-15d708a4de7b@github.com>
 <yAHJVdD3VcYfS0JD5uzAnJQob8VL1QWIh9ZQACfg_Q8=.ab6c01bc-7079-44a1-9a9a-7c252e3311d1@github.com>
Message-ID: <e-VOtQjveXvgKMg9h3ifxNdleXVqdsSSNyQA6VXBDMc=.3a963a98-485c-4c39-9844-3128a1b9f0d0@github.com>

On Fri, 25 Jun 2021 16:34:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One thing, shouldn't that be in JDK 17?

You are right. Oh well, I'll backport it once JDK17 is out. Its not such an important fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4025

From lzang at openjdk.java.net  Sat Jun 26 08:40:06 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 26 Jun 2021 08:40:06 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v27]
In-Reply-To: <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
Message-ID: <4jjkkdtom6j_MOe7UM7QSm2-fSpolYTEF4GCyVRznzI=.a1506ab3-ef0c-4318-ae43-942bf42275d9@github.com>

On Mon, 7 Jun 2021 07:58:26 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - fix build issue after rebase and fix one issue
>  - Merge branch 'master'
>  - Merge branch 'master' into pd
>  - update copyright info
>  - Merge branch 'master' into par-dump
>  - undo JMap.java
>  - code refine and typo fix
>  - Merge branch 'master' into par-dump
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/908aca29...78c2c763

Dear All,
I have made an explaination of the design of this PR. Hope it could be helpful for reviewing. Welcome for any kind of suggestions. 
link: https://docs.google.com/document/d/19iEz5sEJltVuCkFfHsbnzg7ye74OOuB5xO5BaRqVoa8/edit?usp=sharing 
Thanks a lot!

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From dholmes at openjdk.java.net  Sat Jun 26 12:23:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 26 Jun 2021 12:23:58 GMT
Subject: [jdk17] RFR: 8258746: illegal access to global field
 _jvmci_old_thread_counters by terminated thread causes crash
In-Reply-To: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
References: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
Message-ID: <nh92lJ19RAXsfryO-uZJFUX5U1I4MMJ3I_DH1NilP6s=.ef0d4525-f93f-4381-b256-e3f2f6417eb2@github.com>

On Sat, 26 Jun 2021 00:21:26 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change moves the access to the global field _jvmci_old_thread_counters from the thread destructor to JavaThread::exit().  See the JBS issue for more details.  The free of _jvmci_counters is left in the destructor intentionally, as it is allocated in the JavaThread constructor and not all termination paths go through JavaThread::exit().

Hi Dean,

This looks good to me. :)

Good catch on keeping the free of _jvmci_counters in the destructor.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/154

From kvn at openjdk.java.net  Sat Jun 26 13:55:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 26 Jun 2021 13:55:57 GMT
Subject: [jdk17] RFR: 8258746: illegal access to global field
 _jvmci_old_thread_counters by terminated thread causes crash
In-Reply-To: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
References: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
Message-ID: <VP1GYA87SAqfhlus9Ncdhn_GmwG43f7GCZGuEVmkDpk=.fdba593c-749a-4d88-a151-7ff85cc50397@github.com>

On Sat, 26 Jun 2021 00:21:26 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change moves the access to the global field _jvmci_old_thread_counters from the thread destructor to JavaThread::exit().  See the JBS issue for more details.  The free of _jvmci_counters is left in the destructor intentionally, as it is allocated in the JavaThread constructor and not all termination paths go through JavaThread::exit().

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/154

From dlong at openjdk.java.net  Sat Jun 26 20:10:01 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 26 Jun 2021 20:10:01 GMT
Subject: [jdk17] RFR: 8258746: illegal access to global field
 _jvmci_old_thread_counters by terminated thread causes crash
In-Reply-To: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
References: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
Message-ID: <ES6eU7cT-waElIEVoFFL6oaNXoqQfhcTeKdSuXql0B8=.3d688c16-4bb3-4d20-bb1c-c5becef1f8c3@github.com>

On Sat, 26 Jun 2021 00:21:26 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change moves the access to the global field _jvmci_old_thread_counters from the thread destructor to JavaThread::exit().  See the JBS issue for more details.  The free of _jvmci_counters is left in the destructor intentionally, as it is allocated in the JavaThread constructor and not all termination paths go through JavaThread::exit().

Thanks, David and Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/154

From dlong at openjdk.java.net  Sat Jun 26 20:10:02 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 26 Jun 2021 20:10:02 GMT
Subject: [jdk17] Integrated: 8258746: illegal access to global field
 _jvmci_old_thread_counters by terminated thread causes crash
In-Reply-To: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
References: <SplP3WfJAnBWimThMz_9jeIOvRy0NoNB7iDV6ev-PfM=.30be1436-e093-4216-8a9b-42cc904a1d1e@github.com>
Message-ID: <nZ452YBCcZ91dR65SG8mbmBOpKYECPbCeKkwRKZRCMA=.1f337acc-d829-47fa-abd7-e723b7dca031@github.com>

On Sat, 26 Jun 2021 00:21:26 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change moves the access to the global field _jvmci_old_thread_counters from the thread destructor to JavaThread::exit().  See the JBS issue for more details.  The free of _jvmci_counters is left in the destructor intentionally, as it is allocated in the JavaThread constructor and not all termination paths go through JavaThread::exit().

This pull request has now been integrated.

Changeset: d9cb068f
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/d9cb068f4ba85e2be2ebc14e89e739b0a2d90409
Stats:     16 lines in 1 file changed: 11 ins; 5 del; 0 mod

8258746: illegal access to global field _jvmci_old_thread_counters by terminated thread causes crash

Reviewed-by: dholmes, kvn

-------------

PR: https://git.openjdk.java.net/jdk17/pull/154

From dholmes at openjdk.java.net  Sun Jun 27 22:28:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 27 Jun 2021 22:28:28 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads [v3]
In-Reply-To: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
Message-ID: <HLmIPWpTSZNXKlHHcHzJx-iPtAnKN_pjSSyZjKjJ60E=.b554c468-fe51-4159-8021-eb158de3e141@github.com>

> Please review this trivial cleanup to change Thread to JavaThread.
> 
> Testing (in progress):
>   - tiers 1-3 sanity check
>   - GHA
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed alignment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4592/files
  - new: https://git.openjdk.java.net/jdk/pull/4592/files/d84e386d..755222da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4592&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4592&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4592.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4592/head:pull/4592

PR: https://git.openjdk.java.net/jdk/pull/4592

From dholmes at openjdk.java.net  Sun Jun 27 22:28:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 27 Jun 2021 22:28:29 GMT
Subject: RFR: 8269261: The PlaceHolder code uses Thread everywhere but is
 always dealing with JavaThreads [v2]
In-Reply-To: <BGZ10NN2AkwegE9avaPm8M7eM3DRZ5rj7a75RBX_unU=.2d7248c9-a7b0-492a-91d2-b8f761a4f472@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
 <B4tsEdbUDmqENjhYsx7oTF0PMFfpZos3y3qKrzfagFw=.055c9995-b27f-437f-87e8-99f4b3b9d426@github.com>
 <BGZ10NN2AkwegE9avaPm8M7eM3DRZ5rj7a75RBX_unU=.2d7248c9-a7b0-492a-91d2-b8f761a4f472@github.com>
Message-ID: <8g3je0zmCTgsk6pJ0SmVHb45tKilRmtmj-xshJ65P30=.63720eed-c3fc-4445-a413-6e633915ac9a@github.com>

On Fri, 25 Jun 2021 20:33:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed alignment
>
> src/hotspot/share/classfile/placeholders.cpp line 56:
> 
>> 54:    }
>> 55:    JavaThread* thread()                const { return _thread;}
>> 56:    void set_thread(JavaThread* thread) { _thread = thread; }
> 
> Can you line these { up also?

Sure. The above matched the style on that little block of code but I can change both bits.

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4592

From dholmes at openjdk.java.net  Sun Jun 27 22:28:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 27 Jun 2021 22:28:30 GMT
Subject: Integrated: 8269261: The PlaceHolder code uses Thread everywhere but
 is always dealing with JavaThreads
In-Reply-To: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
References: <b_2cFNPHheUz-zW6ehbfpb6GbxYHuV8ztLeLOKzZW-Y=.7e8757c9-0f66-4883-9d59-17f9b61d991d@github.com>
Message-ID: <TbUWhj1Op2w6iMkdl_RqNGwaSpF_NdZTydVC_AospqY=.f5437242-8707-4fae-8bb1-0dc6679c664d@github.com>

On Fri, 25 Jun 2021 01:00:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial cleanup to change Thread to JavaThread.
> 
> Testing (in progress):
>   - tiers 1-3 sanity check
>   - GHA
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 8bed3534
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8bed35343d9143f57af53e8c78d86a7b1cb8ac04
Stats:     21 lines in 2 files changed: 0 ins; 0 del; 21 mod

8269261: The PlaceHolder code uses Thread everywhere but is always dealing with JavaThreads

Reviewed-by: ccheung, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/4592

From dholmes at openjdk.java.net  Mon Jun 28 02:27:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 28 Jun 2021 02:27:06 GMT
Subject: Integrated: 8269003: Update the java manpage for JDK 18
In-Reply-To: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
References: <6XpsY0Nmgl3fDItvlH7Ns30GYAt6H18VTN6qKcx-vV4=.cb756d9e-ffab-44ac-9170-175db986be9b@github.com>
Message-ID: <TKRrU-LW8c9cLXG661G9b5nFn-4u4l5Mi9SzKz-n7-8=.dec1eca7-2937-4aa7-846e-356a96f694f9@github.com>

On Thu, 24 Jun 2021 23:12:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are some start of release changes needed to the manpage that were overlooked:
> 
> - updated "removed options" section to get rid of things removed in 17 (nothing is removed in 18)
> - update list of previous releases (corrected documentation title for JDK 13+)
> 
> The changes are easy to view in the nroff file so I didn't generate the html version.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: f45be151
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f45be1519e84dd0562a841ceb23bcec4dec1437f
Stats:     83 lines in 1 file changed: 3 ins; 75 del; 5 mod

8269003: Update the java manpage for JDK 18

Reviewed-by: minqi

-------------

PR: https://git.openjdk.java.net/jdk/pull/4590

From david.holmes at oracle.com  Mon Jun 28 05:21:17 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 28 Jun 2021 15:21:17 +1000
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <10e8ad8d-ae28-9ce3-3725-1904567c181e@oracle.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
 <10e8ad8d-ae28-9ce3-3725-1904567c181e@oracle.com>
Message-ID: <acb023e2-a29b-589d-e93f-35aa939dd5a7@oracle.com>

On 26/06/2021 8:43 am, David Holmes wrote:
> On 26/06/2021 3:57 am, Coleen Phillimore wrote:
>> In the last pull request on this topic, I was making more general 
>> (mis)statements, but this null threadObj check is only for the case 
>> where we're suspending a thread which already has a threadObj.? This 
>> null check is unnecessary.
> 
> This is probably true, but possibly only because we screen out 
> jni-attaching threads at a higher-level.

I can't quite join all the dots here. If we look at JDWP allThreads 
command, it will call JVM TI GetAllThreads, which uses:

   // enumerate threads (including agent threads)
   ThreadsListEnumerator tle(current_thread, true);

which is implicitly

   ThreadsListEnumerator tle(current_thread, true, true);

from:

   ThreadsListEnumerator(Thread* cur_thread,
                         bool include_jvmti_agent_threads = false,
                         bool include_jni_attaching_threads = true);

so in this case we will return those threads that are still attaching 
and may have no threadObj().

Can such a thread then be used by the JDWP Suspend() command ... it 
means we will get a NULL in the list of jthreads, and the first thing we 
will try to do is call  JVM TI GetThreadLocalStorage - which is 
specified to treat NULL as "use the current thread"! So that seems like 
a bug - but not the bug this PR is concerned about. :)

I'll follow this up with serviceability folk.

Cheers,
David


> Cheers,
> David
> 
>> Tested already with tier1-6 (rerun tier1).
>>
>> -------------
>>
>> Commit messages:
>> ? - 8268902: Testing for threadObj != NULL is unnecessary in suspend 
>> handshake
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/4598/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4598&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8268902
>> ?? Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/4598.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/4598/head:pull/4598
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4598
>>

From david.holmes at oracle.com  Mon Jun 28 05:31:10 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 28 Jun 2021 15:31:10 +1000
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <acb023e2-a29b-589d-e93f-35aa939dd5a7@oracle.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
 <10e8ad8d-ae28-9ce3-3725-1904567c181e@oracle.com>
 <acb023e2-a29b-589d-e93f-35aa939dd5a7@oracle.com>
Message-ID: <ef0ede4e-5d47-db99-01d1-2af6158371c7@oracle.com>

Never mind ...

On 28/06/2021 3:21 pm, David Holmes wrote:
> On 26/06/2021 8:43 am, David Holmes wrote:
>> On 26/06/2021 3:57 am, Coleen Phillimore wrote:
>>> In the last pull request on this topic, I was making more general 
>>> (mis)statements, but this null threadObj check is only for the case 
>>> where we're suspending a thread which already has a threadObj.? This 
>>> null check is unnecessary.
>>
>> This is probably true, but possibly only because we screen out 
>> jni-attaching threads at a higher-level.
> 
> I can't quite join all the dots here. If we look at JDWP allThreads 
> command, it will call JVM TI GetAllThreads, which uses:
> 
>  ? // enumerate threads (including agent threads)
>  ? ThreadsListEnumerator tle(current_thread, true);
> 
> which is implicitly
> 
>  ? ThreadsListEnumerator tle(current_thread, true, true);
> 
> from:
> 
>  ? ThreadsListEnumerator(Thread* cur_thread,
>  ??????????????????????? bool include_jvmti_agent_threads = false,
>  ??????????????????????? bool include_jni_attaching_threads = true);
> 
> so in this case we will return those threads that are still attaching 
> and may have no threadObj().

I overlooked that before we decide to include (or not) JNI attaching 
threads, we have already filtered out any thread with a NULL threadObj().

So no issues.

Sorry for the noise.

David
-----

> Can such a thread then be used by the JDWP Suspend() command ... it 
> means we will get a NULL in the list of jthreads, and the first thing we 
> will try to do is call? JVM TI GetThreadLocalStorage - which is 
> specified to treat NULL as "use the current thread"! So that seems like 
> a bug - but not the bug this PR is concerned about. :)
> 
> I'll follow this up with serviceability folk.
> 
> Cheers,
> David
> 
> 
>> Cheers,
>> David
>>
>>> Tested already with tier1-6 (rerun tier1).
>>>
>>> -------------
>>>
>>> Commit messages:
>>> ? - 8268902: Testing for threadObj != NULL is unnecessary in suspend 
>>> handshake
>>>
>>> Changes: https://git.openjdk.java.net/jdk/pull/4598/files
>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4598&range=00
>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8268902
>>> ?? Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/4598.diff
>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>>> pull/4598/head:pull/4598
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/4598
>>>

From xliu at openjdk.java.net  Mon Jun 28 05:41:09 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 28 Jun 2021 05:41:09 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v4]
In-Reply-To: <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>
Message-ID: <id-wrdw8BmlcMuY-Bi1hK5ggcCPe56c5L7Alg71eFv4=.53ab1a47-c9f4-4bc7-b97f-b7e36887be3f@github.com>

On Fri, 25 Jun 2021 01:22:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments part-2.

Hi, Reviewers, 

May I have another reviewer to take a look at this?  This patch can fix the intermittent crashes for jdk17. 
By rules, we need to 2 reviewers to approve it before we can integrate it. David helped me verify it. 

thanks,
--lx

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From stuefe at openjdk.java.net  Mon Jun 28 06:20:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 06:20:07 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>

On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang <yyang at openjdk.org> wrote:

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Changes requested by stuefe (Reviewer).

src/hotspot/share/runtime/osThread.cpp line 41:

> 39: // Printing
> 40: void OSThread::print_on(outputStream *st) const {
> 41:   st->print("nid=%d ", thread_id());

thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.

src/hotspot/share/runtime/osThread.cpp line 49:

> 47:     case CONDVAR_WAIT:            st->print("waiting on condition ");      break;
> 48:     case OBJECT_WAIT:             st->print("in Object.wait() ");          break;
> 49:     case BREAKPOINTED:            st->print("at breakpoint");               break;

These cleanups don't seem to have anything to do with this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Mon Jun 28 07:40:08 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 07:40:08 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
Message-ID: <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>

On Mon, 28 Jun 2021 06:16:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> src/hotspot/share/runtime/osThread.cpp line 41:
> 
>> 39: // Printing
>> 40: void OSThread::print_on(outputStream *st) const {
>> 41:   st->print("nid=%d ", thread_id());
> 
> thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.

Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:

> src/hotspot/share/runtime/osThread.cpp line 49:
> 
>> 47:     case CONDVAR_WAIT:            st->print("waiting on condition ");      break;
>> 48:     case OBJECT_WAIT:             st->print("in Object.wait() ");          break;
>> 49:     case BREAKPOINTED:            st->print("at breakpoint");               break;
> 
> These cleanups don't seem to have anything to do with this change.

Restored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Mon Jun 28 07:46:29 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 07:46:29 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  restore cleanup code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/eb469267..4baeb175

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Mon Jun 28 08:49:09 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 08:49:09 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
 <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>
Message-ID: <okg8a20YH5FvAJ1WAzvclWnkdlgCh_soQtOhKbnDeHM=.fcfe5f77-3726-4248-b272-8a0486ff1a8f@github.com>

On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> src/hotspot/share/runtime/osThread.cpp line 41:
>> 
>>> 39: // Printing
>>> 40: void OSThread::print_on(outputStream *st) const {
>>> 41:   st->print("nid=%d ", thread_id());
>> 
>> thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.
>
> Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:

You'd do:

print("nid: " UINT64_FORMAT, (uint64_t) id):;

thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Mon Jun 28 09:01:10 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 28 Jun 2021 09:01:10 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
Message-ID: <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>

On Mon, 28 Jun 2021 07:46:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore cleanup code

Hi,
If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
So this depends on your tools.  Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't.  Maybe this change delights some users and frustrates others.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Mon Jun 28 09:20:02 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 09:20:02 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
 <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>
Message-ID: <f_BZsAk3c7Yn7jUh0V9wyru1I8lw2ewWyDGcJKr-1RQ=.42ea8d53-c4cd-4dcc-877c-94b120ad1410@github.com>

On Mon, 28 Jun 2021 08:58:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi,
> If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
> So this depends on your tools. Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't. Maybe this change delights some users and frustrates others.

Why not do it platform dependent then? This would make sense especially since the type is opaque. Let each platform handling printing. Windows can hex-print its DWORD thread id. Linux can print its kernel LWP. And platforms where the thread id is 64bit, or a structure, can print that.

For now default implementations could live in `os::Windows::print_thread_id(thread_t)` and `os::Posix::print_thread_id(thread_t)`, respectively.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Mon Jun 28 10:10:02 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 28 Jun 2021 10:10:02 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <f_BZsAk3c7Yn7jUh0V9wyru1I8lw2ewWyDGcJKr-1RQ=.42ea8d53-c4cd-4dcc-877c-94b120ad1410@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
 <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>
 <f_BZsAk3c7Yn7jUh0V9wyru1I8lw2ewWyDGcJKr-1RQ=.42ea8d53-c4cd-4dcc-877c-94b120ad1410@github.com>
Message-ID: <HfTDsxn4EpZunPUYvQQhF1KXfOxRP-f2tyg_s_cUq_4=.d140212e-ac63-48a5-8adc-8cc16d555348@github.com>

On Mon, 28 Jun 2021 09:16:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why not do it platform dependent then? ...

Checked Visual Studio, and that goes with decimal for thread IDs. 8-)

It's the tools rather than the platform.  But yes, hex for thread IDs seems to be in the minority.  (I have occasionally found this annoying.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From david.holmes at oracle.com  Mon Jun 28 12:37:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 28 Jun 2021 22:37:57 +1000
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <okg8a20YH5FvAJ1WAzvclWnkdlgCh_soQtOhKbnDeHM=.fcfe5f77-3726-4248-b272-8a0486ff1a8f@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
 <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>
 <okg8a20YH5FvAJ1WAzvclWnkdlgCh_soQtOhKbnDeHM=.fcfe5f77-3726-4248-b272-8a0486ff1a8f@github.com>
Message-ID: <550a3797-9694-b4f3-1e64-c556210194b0@oracle.com>

On 28/06/2021 6:49 pm, Thomas Stuefe wrote:
> On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang <yyang at openjdk.org> wrote:
> 
>>> src/hotspot/share/runtime/osThread.cpp line 41:
>>>
>>>> 39: // Printing
>>>> 40: void OSThread::print_on(outputStream *st) const {
>>>> 41:   st->print("nid=%d ", thread_id());
>>>
>>> thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.
>>
>> Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:
> 
> You'd do:
> 
> print("nid: " UINT64_FORMAT, (uint64_t) id):;
> 
> thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.

If it is opaque then I don't see how signed or unsigned makes any 
difference. You are assuming it can just be treated as a 64-bit value; 
whether you interpret that as a signed or unsigned value just changes 
how you print it. I agree printing only positive values is nicer visually.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4449
> 

From coleen.phillimore at oracle.com  Mon Jun 28 13:07:42 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 28 Jun 2021 09:07:42 -0400
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <ef0ede4e-5d47-db99-01d1-2af6158371c7@oracle.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
 <10e8ad8d-ae28-9ce3-3725-1904567c181e@oracle.com>
 <acb023e2-a29b-589d-e93f-35aa939dd5a7@oracle.com>
 <ef0ede4e-5d47-db99-01d1-2af6158371c7@oracle.com>
Message-ID: <fb8de28d-f4d2-9b22-8da5-8208307684d0@oracle.com>



On 6/28/21 1:31 AM, David Holmes wrote:
> Never mind ...
>
> On 28/06/2021 3:21 pm, David Holmes wrote:
>> On 26/06/2021 8:43 am, David Holmes wrote:
>>> On 26/06/2021 3:57 am, Coleen Phillimore wrote:
>>>> In the last pull request on this topic, I was making more general 
>>>> (mis)statements, but this null threadObj check is only for the case 
>>>> where we're suspending a thread which already has a threadObj.? 
>>>> This null check is unnecessary.
>>>
>>> This is probably true, but possibly only because we screen out 
>>> jni-attaching threads at a higher-level.
>>
>> I can't quite join all the dots here. If we look at JDWP allThreads 
>> command, it will call JVM TI GetAllThreads, which uses:
>>
>> ?? // enumerate threads (including agent threads)
>> ?? ThreadsListEnumerator tle(current_thread, true);
>>
>> which is implicitly
>>
>> ?? ThreadsListEnumerator tle(current_thread, true, true);
>>
>> from:
>>
>> ?? ThreadsListEnumerator(Thread* cur_thread,
>> ???????????????????????? bool include_jvmti_agent_threads = false,
>> ???????????????????????? bool include_jni_attaching_threads = true);
>>
>> so in this case we will return those threads that are still attaching 
>> and may have no threadObj().
>
> I overlooked that before we decide to include (or not) JNI attaching 
> threads, we have already filtered out any thread with a NULL threadObj().

I was looking further down the call stack to the jvmti_SuspendThread

static jvmtiError JNICALL
jvmti_SuspendThread(jvmtiEnv* env,
 ??????????? jthread thread) {

But interestingly, this ThreadsListEnumerator also filters out threadObj 
== NULL because it returns the list of threadObj.

Thanks for digging deeper.? You usually find what I miss!? Thanks
Coleen


>
> So no issues.
>
> Sorry for the noise.
>
> David
> -----
>
>> Can such a thread then be used by the JDWP Suspend() command ... it 
>> means we will get a NULL in the list of jthreads, and the first thing 
>> we will try to do is call? JVM TI GetThreadLocalStorage - which is 
>> specified to treat NULL as "use the current thread"! So that seems 
>> like a bug - but not the bug this PR is concerned about. :)
>>
>> I'll follow this up with serviceability folk.
>>
>> Cheers,
>> David
>>
>>
>>> Cheers,
>>> David
>>>
>>>> Tested already with tier1-6 (rerun tier1).
>>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>> ? - 8268902: Testing for threadObj != NULL is unnecessary in 
>>>> suspend handshake
>>>>
>>>> Changes: https://git.openjdk.java.net/jdk/pull/4598/files
>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4598&range=00
>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8268902
>>>> ?? Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/4598.diff
>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>>>> pull/4598/head:pull/4598
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/4598
>>>>


From kevinw at openjdk.java.net  Mon Jun 28 13:10:04 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 28 Jun 2021 13:10:04 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>
Message-ID: <37m5nc6KDsehgna2Z7xEbz_J5iodCHhUQgpcnXxVEIk=.5cea815d-6cfa-42d2-ba81-391aaaffb1d2@github.com>

On Fri, 18 Jun 2021 06:14:49 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Do you think this would facilitate debugging process? And is it acceptable? Any feedback is appreciated!

My first comments were to say that this makes things better for some people, but a little worse for others.
Maybe overall this looks like it makes things better for most people. 8-)

If so (and if we don't discover more tools that prefer hex for thread IDs!), then we want to be consistent, so in addition to the native/built in implementation, we should also update:

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
..to keep the SA implementation in sync.  It would be odd to have thread dumps looking more different depending on what generated them.

And if changing that, also change:
test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java

I don't see other tests that parse this information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From coleenp at openjdk.java.net  Mon Jun 28 13:16:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 28 Jun 2021 13:16:05 GMT
Subject: RFR: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
Message-ID: <vYPTZ8K8bvi3tjYPpkqkaCxhawR40EvhmUIFdMM1IiI=.aaf89219-fc68-469c-9dfc-142761132e0d@github.com>

On Fri, 25 Jun 2021 17:50:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.
> Tested already with tier1-6 (rerun tier1).

Thanks for the code reviews and investigations.  Sorry the gitbot changed the punctuation on my email to question marks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4598

From coleenp at openjdk.java.net  Mon Jun 28 13:16:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 28 Jun 2021 13:16:06 GMT
Subject: Integrated: 8268902: Testing for threadObj != NULL is unnecessary in
 suspend handshake
In-Reply-To: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
References: <0rZLysNpp0xm86buNOk7erW3foqIezI1eBYiX9egPo4=.1d41de5f-512e-494c-8d81-9e7b28ea2632@github.com>
Message-ID: <Di5kMvj8UxD35F8DhBzUB8bS2FbE942zG-G3B3VWDlc=.de715ed3-1495-41be-81f0-b1443f35f5fd@github.com>

On Fri, 25 Jun 2021 17:50:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In the last pull request on this topic, I was making more general (mis)statements, but this null threadObj check is only for the case where we're suspending a thread which already has a threadObj.  This null check is unnecessary.
> Tested already with tier1-6 (rerun tier1).

This pull request has now been integrated.

Changeset: 29bc381d
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29bc381da517001251975b6d634c4f779ff1319a
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8268902: Testing for threadObj != NULL is unnecessary in suspend handshake

Reviewed-by: pchilanomate, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/4598

From stuefe at openjdk.java.net  Mon Jun 28 13:50:14 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 13:50:14 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <550a3797-9694-b4f3-1e64-c556210194b0@oracle.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <550a3797-9694-b4f3-1e64-c556210194b0@oracle.com>
Message-ID: <ppYWQCM55LtWK2SS6PJTF5de1pOIUWz2iAG6b4fXrNU=.a5c8365b-ee50-48e7-8915-a472a9534f08@github.com>

On Mon, 28 Jun 2021 12:41:35 GMT, David Holmes <david.holmes at oracle.com> wrote:

> > You'd do:
> > print("nid: " UINT64_FORMAT, (uint64_t) id):;
> > thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.
> 
> If it is opaque then I don't see how signed or unsigned makes any
> difference. You are assuming it can just be treated as a 64-bit value;
> whether you interpret that as a signed or unsigned value just changes
> how you print it. I agree printing only positive values is nicer visually.
> 
> David

My `signed in` comment was referring to the existing use of `%d` in the code base. I'm more concerned with the 32bit range of int than the signedness (though I never saw an OS tool displaying negative numbers for thread ids).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From phh at openjdk.java.net  Mon Jun 28 14:56:07 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Mon, 28 Jun 2021 14:56:07 GMT
Subject: [jdk17] RFR: 8267952: async logging supports to dynamically
 change tags and decorators [v4]
In-Reply-To: <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
 <e-tfXB7hhG-L2OoDaFLXm_wZ3C5dWDktj-Jpptzwl-w=.2c1d61e2-34af-4927-b50e-a5eb1e2ae3de@github.com>
Message-ID: <z6k28lVvrnRdjMwdghrn8OvKV3Y4mNaK7QUkxUj-9Qc=.9f9fec68-fee7-4fc5-b748-48fe7b680e30@github.com>

On Fri, 25 Jun 2021 01:22:23 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
>> is that previous flush() can't guarantee flush all pending messages in AsyncLog
>> buffer. This patch implements flush() using a synchronizaton token and waits for
>> completion. This approach isn't MT-safe but it can serialize all flush() calls in
>> a thread. 
>> 
>> Two concurrent tests are appended to cover the hazard cases.
>> This patch also comments LogConfiguration::configure_output() MT-safety.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments part-2.

Looks good.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/130

From pchilanomate at openjdk.java.net  Mon Jun 28 16:32:17 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 28 Jun 2021 16:32:17 GMT
Subject: RFR: 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
Message-ID: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>

Hi,

Please review this small fix to test ParallelSuperTest.java. I only saw the timeout once on one of my GHA tests but the issue can be easily reproduced by adding a delay in startLoading() before the main thread tries to synchronize on thread_sync.
Run the test with and without the added delay. The test times out without the patch and passes with the patch.

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.java.net/jdk/pull/4614/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4614&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269530
  Stats: 22 lines in 2 files changed: 4 ins; 4 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4614.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4614/head:pull/4614

PR: https://git.openjdk.java.net/jdk/pull/4614

From dcubed at openjdk.java.net  Mon Jun 28 17:12:19 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 28 Jun 2021 17:12:19 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
Message-ID: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>

A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

-------------

Commit messages:
 - 8269534: Remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Changes: https://git.openjdk.java.net/jdk17/pull/164/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=164&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269534
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/164/head:pull/164

PR: https://git.openjdk.java.net/jdk17/pull/164

From tschatzl at openjdk.java.net  Mon Jun 28 17:18:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 28 Jun 2021 17:18:02 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
Message-ID: <-c9FPOcv71mdWZKgiakejb-vZeh3Zxq8Y4ZVniLbogI=.d856f392-c8b5-4c37-aab8-1f808d3abc53@github.com>

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Lgtm and trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/164

From iignatyev at openjdk.java.net  Mon Jun 28 17:18:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 28 Jun 2021 17:18:02 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
Message-ID: <46tT_FluMBxBftmZG5JHlr3NNZdrITGiOwu_QKmddx0=.af2a492e-7ef7-4a54-b486-3ca1e554853d@github.com>

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Marked as reviewed by iignatyev (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/164

From dcubed at openjdk.java.net  Mon Jun 28 17:22:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 28 Jun 2021 17:22:08 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <46tT_FluMBxBftmZG5JHlr3NNZdrITGiOwu_QKmddx0=.af2a492e-7ef7-4a54-b486-3ca1e554853d@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
 <46tT_FluMBxBftmZG5JHlr3NNZdrITGiOwu_QKmddx0=.af2a492e-7ef7-4a54-b486-3ca1e554853d@github.com>
Message-ID: <1yv09Kcow1We74im_mS331DWz6S8-3R18wXGdylf73Y=.63902f46-1d43-4ca4-9d6e-582cf601f046@github.com>

On Mon, 28 Jun 2021 17:15:23 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
>
> Marked as reviewed by iignatyev (Reviewer).

@iignatev and @tschatzl - Thanks for the fast reviews.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/164

From dcubed at openjdk.java.net  Mon Jun 28 17:33:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 28 Jun 2021 17:33:07 GMT
Subject: [jdk17] Integrated: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
Message-ID: <xx6sEyCgIC_UKMZwac-qVedlQX3CiqmwWJyU8km0pEQ=.465ab527-fcd6-4164-9d28-1fd23cd40df6@github.com>

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

This pull request has now been integrated.

Changeset: 20640a57
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/20640a57f3a352a046006d4795afa4a64f4dc92d
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8269534: Remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Reviewed-by: iignatyev, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk17/pull/164

From jvernee at openjdk.java.net  Mon Jun 28 17:44:28 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 17:44:28 GMT
Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java
 test failed with concurrent GC
Message-ID: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>

This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.

Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.

I've changed these 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks (now handled by the call).

FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.

Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

-------------

Commit messages:
 - Remove whitespace
 - Add Shenandoah test case as well
 - Add zgc requires tags
 - Typo in MACOS_AARCH64_ONLY part
 - Polish
 - Some more build fixes
 - build fixes
 - re-write upcall code to mimic JavaCallWrapper

Changes: https://git.openjdk.java.net/jdk17/pull/149/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269240
  Stats: 516 lines in 18 files changed: 338 ins; 147 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Mon Jun 28 17:44:29 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 17:44:29 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>

On Fri, 25 Jun 2021 17:38:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> I've changed these 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks (now handled by the call).
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

src/hotspot/cpu/arm/frame_arm.cpp line 320:

> 318:   return nullptr;
> 319: }
> 320: 

FWIW, stubs were missing on some platforms, and this seems to have been fine before, but now started causing compilation errors, so I've added them here.

src/hotspot/share/runtime/safepoint.cpp line 931:

> 929:     // See if return type is an oop.
> 930:     bool return_oop = nm->method()->is_returning_oop();
> 931:     HandleMark hm(self);

I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).

src/hotspot/share/runtime/thread.cpp line 1974:

> 1972:   assert(deferred_card_mark().is_empty(), "Should be empty during GC");
> 1973: 
> 1974:   // Traverse the GCHandles

I reduced some duplication here while debugging, but this change is not strictly needed (though a nice cleanup, IMO). Let me know, and I could remove this part if preferred.

test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java line 78:

> 76:  *   TestAsyncStackWalk
> 77:  */
> 78:  

Suggestion:

test/jdk/java/foreign/stackwalk/TestStackWalk.java line 78:

> 76:  *   TestStackWalk
> 77:  */
> 78:  

Suggestion:

-------------

PR: https://git.openjdk.java.net/jdk17/pull/149

From xliu at openjdk.java.net  Mon Jun 28 18:21:10 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 28 Jun 2021 18:21:10 GMT
Subject: [jdk17] Integrated: 8267952: async logging supports to dynamically
 change tags and decorators
In-Reply-To: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
References: <CQ_Y28HBx4TWyUoxl8VtbHfSCamwWT4H0TaZwydLbtw=.c0779d93-857a-4551-8b4e-9a52e5864562@github.com>
Message-ID: <tsgm1fgeirQjZUwJP8-2NLQBY1jq8PiIpl71yQxT6rU=.94ae9e36-83c6-441e-82c0-232eb618aebd@github.com>

On Wed, 23 Jun 2021 20:18:32 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch fixed intermittent crashes of gtest/AsyncLogGtest.java. The root cause 
> is that previous flush() can't guarantee flush all pending messages in AsyncLog
> buffer. This patch implements flush() using a synchronizaton token and waits for
> completion. This approach isn't MT-safe but it can serialize all flush() calls in
> a thread. 
> 
> Two concurrent tests are appended to cover the hazard cases.
> This patch also comments LogConfiguration::configure_output() MT-safety.

This pull request has now been integrated.

Changeset: 09bb8468
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/09bb84685fd959157857cf7739aedddd4a5e0cee
Stats:     198 lines in 9 files changed: 156 ins; 13 del; 29 mod

8267952: async logging supports to dynamically change tags and decorators

Reviewed-by: dholmes, phh

-------------

PR: https://git.openjdk.java.net/jdk17/pull/130

From ccheung at openjdk.java.net  Mon Jun 28 19:06:31 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 28 Jun 2021 19:06:31 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN
Message-ID: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>

Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.

Testing: 
- [x] tiers 1,2.

-------------

Commit messages:
 - 8263640: hs_err improvement: handle class path longer than O_BUFLEN

Changes: https://git.openjdk.java.net/jdk/pull/4616/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263640
  Stats: 92 lines in 2 files changed: 91 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4616/head:pull/4616

PR: https://git.openjdk.java.net/jdk/pull/4616

From iklam at openjdk.java.net  Mon Jun 28 21:04:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 28 Jun 2021 21:04:07 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN
In-Reply-To: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
Message-ID: <GlCugURFI__Y3z-hghSqBNEKG6FRcnJlJPbIUTm2I2U=.ed8b0c20-8ed2-474f-8110-bd78e3e9acc2@github.com>

On Mon, 28 Jun 2021 18:57:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
> 
> Testing: 
> - [x] tiers 1,2.

Changes requested by iklam (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 1122:

> 1120:       }
> 1121:       st->cr();
> 1122:     }

Maybe we can use `st->print_raw()` instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From sspitsyn at openjdk.java.net  Mon Jun 28 21:47:09 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 28 Jun 2021 21:47:09 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <AWr51Whh-2a-xPaKBOrS9NVSH203FugabPTL65Inxc0=.7cc4dc46-a83b-42b7-87a3-4edf9594fffe@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Despite the fact it is after the integration it looks good to me. :)
Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From ccheung at openjdk.java.net  Mon Jun 28 22:43:39 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 28 Jun 2021 22:43:39 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v2]
In-Reply-To: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
Message-ID: <gblEb7Z55fLUh8fpFB9Idxho7nDXs9HAsIgy8Xs9nM0=.e8ae57c4-2531-40e7-8bd1-7afd7776dcde@github.com>

> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
> 
> Testing: 
> - [x] tiers 1,2.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comment and removed the @requires vm.cds from the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4616/files
  - new: https://git.openjdk.java.net/jdk/pull/4616/files/b3f9a075..60ecf197

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4616/head:pull/4616

PR: https://git.openjdk.java.net/jdk/pull/4616

From ccheung at openjdk.java.net  Mon Jun 28 22:43:43 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 28 Jun 2021 22:43:43 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v2]
In-Reply-To: <GlCugURFI__Y3z-hghSqBNEKG6FRcnJlJPbIUTm2I2U=.ed8b0c20-8ed2-474f-8110-bd78e3e9acc2@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <GlCugURFI__Y3z-hghSqBNEKG6FRcnJlJPbIUTm2I2U=.ed8b0c20-8ed2-474f-8110-bd78e3e9acc2@github.com>
Message-ID: <0VmyvbzpJcaMjl5sF4KOClpBujhCur7it8Z3wOB2gFE=.74539f19-ae43-4d84-922a-d1c7bce4b377@github.com>

On Mon, 28 Jun 2021 21:00:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam comment and removed the @requires vm.cds from the test
>
> src/hotspot/share/runtime/arguments.cpp line 1122:
> 
>> 1120:       }
>> 1121:       st->cr();
>> 1122:     }
> 
> Maybe we can use `st->print_raw()` instead?

Thanks for your review.
I've changed it to st->print_raw_cr() so that st->cr() is not needed.
I also removed the "@requires vm.cds" from the test since it is unrelated to cds.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From iklam at openjdk.java.net  Mon Jun 28 22:58:05 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 28 Jun 2021 22:58:05 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v2]
In-Reply-To: <0VmyvbzpJcaMjl5sF4KOClpBujhCur7it8Z3wOB2gFE=.74539f19-ae43-4d84-922a-d1c7bce4b377@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <GlCugURFI__Y3z-hghSqBNEKG6FRcnJlJPbIUTm2I2U=.ed8b0c20-8ed2-474f-8110-bd78e3e9acc2@github.com>
 <0VmyvbzpJcaMjl5sF4KOClpBujhCur7it8Z3wOB2gFE=.74539f19-ae43-4d84-922a-d1c7bce4b377@github.com>
Message-ID: <OedG0r_Vz0mIHViBR9CJRVKG781QBcmoCtyf_6TQYbk=.04136f58-fcf5-4e8d-8820-66e279e2a358@github.com>

On Mon, 28 Jun 2021 22:39:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1122:
>> 
>>> 1120:       }
>>> 1121:       st->cr();
>>> 1122:     }
>> 
>> Maybe we can use `st->print_raw()` instead?
>
> Thanks for your review.
> I've changed it to st->print_raw_cr() so that st->cr() is not needed.
> I also removed the "@requires vm.cds" from the test since it is unrelated to cds.

How about doing this? This will make sure the print_raw_cr() path is tested (i.e., when generating hs_err files).


  if (len == 0) {
    st->print_raw_cr("<not set>");
  } else {
    st->print_raw_cr(path, len);
  }

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From iklam at openjdk.java.net  Mon Jun 28 22:58:04 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 28 Jun 2021 22:58:04 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v2]
In-Reply-To: <gblEb7Z55fLUh8fpFB9Idxho7nDXs9HAsIgy8Xs9nM0=.e8ae57c4-2531-40e7-8bd1-7afd7776dcde@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gblEb7Z55fLUh8fpFB9Idxho7nDXs9HAsIgy8Xs9nM0=.e8ae57c4-2531-40e7-8bd1-7afd7776dcde@github.com>
Message-ID: <RZUlOQgw04gex-7qmYdPfz8gzYLOlicOdvymV3jDEEw=.a5dbb640-a546-4e07-abec-77de09f9d7ca@github.com>

On Mon, 28 Jun 2021 22:43:39 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
>> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
>> 
>> Testing: 
>> - [x] tiers 1,2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment and removed the @requires vm.cds from the test

Changes requested by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From iklam at openjdk.java.net  Mon Jun 28 23:16:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 28 Jun 2021 23:16:09 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v4]
In-Reply-To: <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
Message-ID: <QwNVhIicAmaAkRkJAgRvrEeZogJrECzs2z4mUhWVVHc=.89587905-c631-45d3-a50c-636ba8201338@github.com>

On Fri, 25 Jun 2021 01:15:29 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
>> 
>> Tests: tier1,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 'Shared' from class names and rename corresponding files

This looks OK to me.

The naming of the various classes is still not consistent since the code has evolved for a long time. It was probably a mistake to add `Shared` as a classname suffix, but that was done since the beginning of CDS.

Maybe eventually we should rename all the classes with a CDS prefix (similar to the JFR code). That should be done in a separate PR, though.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4568

From minqi at openjdk.java.net  Mon Jun 28 23:24:10 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 28 Jun 2021 23:24:10 GMT
Subject: RFR: 8268821: Split systemDictionaryShared.cpp [v4]
In-Reply-To: <QwNVhIicAmaAkRkJAgRvrEeZogJrECzs2z4mUhWVVHc=.89587905-c631-45d3-a50c-636ba8201338@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
 <R3O6RnriyFJXFPhEE1JNIeoMOdh17gP6q4wCrHa-swY=.e98aa54c-a5f3-4203-8ab1-b4e5f09f63aa@github.com>
 <QwNVhIicAmaAkRkJAgRvrEeZogJrECzs2z4mUhWVVHc=.89587905-c631-45d3-a50c-636ba8201338@github.com>
Message-ID: <99AV785OIEfDIgLnLh3qyKg1CLe5Y56eu75KNU4YstE=.84feb293-0d74-415d-9d20-a348f530e2b2@github.com>

On Mon, 28 Jun 2021 23:13:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove 'Shared' from class names and rename corresponding files
>
> This looks OK to me.
> 
> The naming of the various classes is still not consistent since the code has evolved for a long time. It was probably a mistake to add `Shared` as a classname suffix, but that was done since the beginning of CDS.
> 
> Maybe eventually we should rename all the classes with a CDS prefix (similar to the JFR code). That should be done in a separate PR, though.

@iklam @calvinccheung @erikj79 
Thank you for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From minqi at openjdk.java.net  Mon Jun 28 23:24:11 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 28 Jun 2021 23:24:11 GMT
Subject: Integrated: 8268821: Split systemDictionaryShared.cpp
In-Reply-To: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
References: <Kz4UO6dqKBb77dTG6PlNAp_hLVHigily4O_ARP4X78c=.2c63f3bd-89a3-4746-adfb-50992ad96405@github.com>
Message-ID: <1vHh8G-eTHl5MsDSYPFQBQPzLvt0aU_tGA2AkALiXPM=.f9993fb3-3685-4b53-aae2-a0f53548677f@github.com>

On Wed, 23 Jun 2021 06:08:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> systemDictionaryShared becomes fatter and fatter so it is time to split it into functional files. Moved security and jar operation related code into CDSProtectionDomain, and moved shared class info (DumpTime/RunTime) to sharedClassInfo.[ch]pp, also moved lambda proxy related to lambdaProxyClassInfo.hpp. This way systemDictionaryShared.cpp looks neat and light.
> 
> Tests: tier1,tier3,tier4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: ee1e202b
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee1e202bc36b8413e33b7b9e4c9f7a0601bf9a63
Stats:     2757 lines in 15 files changed: 1411 ins; 1101 del; 245 mod

8268821: Split systemDictionaryShared.cpp

Reviewed-by: erikj, ccheung, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/4568

From ccheung at openjdk.java.net  Mon Jun 28 23:40:40 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 28 Jun 2021 23:40:40 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
Message-ID: <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>

> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
> 
> Testing: 
> - [x] tiers 1,2.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  use st->print_raw_cr() on all lengths of class path

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4616/files
  - new: https://git.openjdk.java.net/jdk/pull/4616/files/60ecf197..b4b645cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4616/head:pull/4616

PR: https://git.openjdk.java.net/jdk/pull/4616

From ccheung at openjdk.java.net  Mon Jun 28 23:40:43 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 28 Jun 2021 23:40:43 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v2]
In-Reply-To: <gblEb7Z55fLUh8fpFB9Idxho7nDXs9HAsIgy8Xs9nM0=.e8ae57c4-2531-40e7-8bd1-7afd7776dcde@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gblEb7Z55fLUh8fpFB9Idxho7nDXs9HAsIgy8Xs9nM0=.e8ae57c4-2531-40e7-8bd1-7afd7776dcde@github.com>
Message-ID: <Qy-axzduUlDBemyF7-LDGe23ALhngYX2515roJhUojs=.810d6940-dacd-44ca-ac8c-8ca8810bd417@github.com>

On Mon, 28 Jun 2021 22:43:39 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
>> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
>> 
>> Testing: 
>> - [x] tiers 1,2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment and removed the @requires vm.cds from the test

Updated to use `st->print_raw_cr()` on all lengths of class path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From minqi at openjdk.java.net  Tue Jun 29 01:00:07 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 29 Jun 2021 01:00:07 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
Message-ID: <yyUk97NRTu3UvGbQemXqNZvw86op1hJJcEhJfVFTDOk=.725e4632-9af5-434e-9609-783d6e2d34eb@github.com>

On Mon, 28 Jun 2021 23:40:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
>> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
>> 
>> Testing: 
>> - [x] tiers 1,2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use st->print_raw_cr() on all lengths of class path

Look good.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4616

From dholmes at openjdk.java.net  Tue Jun 29 02:37:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 02:37:07 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
Message-ID: <aduk2m4LYgz8O-xFTcn8D6f28E34I40btoWBgS2oSVg=.ed212de9-7525-4574-8d67-228469eb206b@github.com>

On Mon, 28 Jun 2021 23:40:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
>> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
>> 
>> Testing: 
>> - [x] tiers 1,2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use st->print_raw_cr() on all lengths of class path

Seems like a simpler solution than previously discussed - please update the bug report.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4616

From dholmes at openjdk.java.net  Tue Jun 29 02:37:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 02:37:07 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <OedG0r_Vz0mIHViBR9CJRVKG781QBcmoCtyf_6TQYbk=.04136f58-fcf5-4e8d-8820-66e279e2a358@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <GlCugURFI__Y3z-hghSqBNEKG6FRcnJlJPbIUTm2I2U=.ed8b0c20-8ed2-474f-8110-bd78e3e9acc2@github.com>
 <0VmyvbzpJcaMjl5sF4KOClpBujhCur7it8Z3wOB2gFE=.74539f19-ae43-4d84-922a-d1c7bce4b377@github.com>
 <OedG0r_Vz0mIHViBR9CJRVKG781QBcmoCtyf_6TQYbk=.04136f58-fcf5-4e8d-8820-66e279e2a358@github.com>
Message-ID: <NXYvh1GqXKnmT7oFEXmKHqlGXmAMyXJKELUvcL7deJA=.e4cb0dac-fb3d-4682-9ec6-31defeeaaa0b@github.com>

On Mon, 28 Jun 2021 22:54:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thanks for your review.
>> I've changed it to st->print_raw_cr() so that st->cr() is not needed.
>> I also removed the "@requires vm.cds" from the test since it is unrelated to cds.
>
> How about doing this? This will make sure the print_raw_cr() path is tested (i.e., when generating hs_err files).
> 
> 
>   if (len == 0) {
>     st->print_raw_cr("<not set>");
>   } else {
>     st->print_raw_cr(path, len);
>   }

Please add a comment why print_raw is used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From dholmes at openjdk.java.net  Tue Jun 29 02:48:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 02:48:02 GMT
Subject: RFR: 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
In-Reply-To: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
References: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
Message-ID: <DfExQFYm4h5VlHuoyRX9nSUVsUbpNQ-BBbQopOO0Iww=.55903aa4-5e2a-4591-8029-676682efbd40@github.com>

On Mon, 28 Jun 2021 16:18:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to test ParallelSuperTest.java. I only saw the timeout once on one of my GHA tests but the issue can be easily reproduced by adding a delay in startLoading() before the main thread tries to synchronize on thread_sync.
> Run the test with and without the added delay. The test times out without the patch and passes with the patch.
> 
> Thanks,
> Patricio

Hi Patricio,

The switch to Semaphore looks good. There should never be a use of Object.wait without there being a state variable that controls the wait! Not sure how this got through originally. :(

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4614

From yyang at openjdk.java.net  Tue Jun 29 03:30:06 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 29 Jun 2021 03:30:06 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <37m5nc6KDsehgna2Z7xEbz_J5iodCHhUQgpcnXxVEIk=.5cea815d-6cfa-42d2-ba81-391aaaffb1d2@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>
 <37m5nc6KDsehgna2Z7xEbz_J5iodCHhUQgpcnXxVEIk=.5cea815d-6cfa-42d2-ba81-391aaaffb1d2@github.com>
Message-ID: <OGTLUlw8eHXmoe1RFgEbwcaUR1tkmt1rOgHwAbCnS-o=.e627354a-d402-4a0a-9785-f42bca1d1fec@github.com>

On Mon, 28 Jun 2021 13:07:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> If so (and if we don't discover more tools that prefer hex for thread IDs!), then we want to be consistent, so in addition to the native/built in implementation, we should also update:

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
..to keep the SA implementation in sync. It would be odd to have thread dumps looking more different depending on what generated them.

> And if changing that, also change:
test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java

Thanks for the comments! I will change the corresponding SA implementation and tests.


> > Hi,
> > If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
> > So this depends on your tools. Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't. Maybe this change delights some users and frustrates others.
> 
> Why not do it platform dependent then? This would make sense especially since the type is opaque. Let each platform handling printing. Windows can hex-print its DWORD thread id. Linux can print its kernel LWP. And platforms where the thread id is 64bit, or a structure, can print that.
> 
> For now default implementations could live in `os::Windows::print_thread_id(thread_t)` and `os::Posix::print_thread_id(thread_t)`, respectively.

Will it be too heavy to add a platform-dependent implementation for this small function? As Kevin said, maybe this change delights some users and frustrates others. But since POSIX is the vast majority of users, it may be a better choice to adapt to them. Just IMHO..

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Tue Jun 29 03:42:32 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 29 Jun 2021 03:42:32 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v3]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  use UINT64_FORMAT; change SA and test impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/4baeb175..0f230755

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=01-02

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Tue Jun 29 07:15:23 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 29 Jun 2021 07:15:23 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and invocation
 count
Message-ID: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>

At the moment NMT prints a total of reserved and committed bytes. If one wants to know how much C-Heap the VM uses, one needs to add all numbers from the sub categories.

It would be helpful would NMT print the total number of malloced memory and additionally the malloc invocation count.

----

This patch modifes the printout to print, in addition to totals, the number of malloced bytes, malloc invocation counts, and number of mmap reserved/committed bytes. This mirrors the way we print individual sub categories and allocation sites.

Before:

Native Memory Tracking:

Total: reserved=18489703KB, committed=1183967KB


After:


Native Memory Tracking:

Total: reserved=18491726KB, committed=1183178KB
       malloc: 40590KB #13669
       mmap:   reserved=18451136KB, committed=1142588KB


Tests: Ran hotspot/runtime/NMT jtreg tests.

-------------

Commit messages:
 - start

Changes: https://git.openjdk.java.net/jdk/pull/4622/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4622&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269571
  Stats: 25 lines in 3 files changed: 20 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4622/head:pull/4622

PR: https://git.openjdk.java.net/jdk/pull/4622

From nekocaffeine at qq.com  Tue Jun 29 07:57:07 2021
From: nekocaffeine at qq.com (=?ISO-8859-1?B?TmVrb0NhZmZlaW5l?=)
Date: Tue, 29 Jun 2021 15:57:07 +0800
Subject: Confusion about stack map verify of constructors
Message-ID: <tencent_A12602702043AD722D2BC68C9AC929C77206@qq.com>

Hi everyone,


When a super constructor is called in a TryCatchBlock,
&nbsp;none of the following exception handler locals will pass validation,
&nbsp;uninitializedThis, referenceName, TOP, <empty&gt;, java/lang/Object.


Where uninitializedThis and referenceName are mutually exclusive,
&nbsp;and either one will fail because it does not contain the other.
TOP will fail because it is not compatible with the flags of uninitializedThis.
<empty&gt; will fail for incompatibility with uninitializedThis.


Is there a stackframe that passes validation?


Thanks in advance,
NekoCaffeine

From zgu at openjdk.java.net  Tue Jun 29 11:22:06 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 29 Jun 2021 11:22:06 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
Message-ID: <nlaaEsNjq33PVFalYg8mOm9de6VI0Z4sDBPiD0ZDi68=.e12e3b6e-e382-47b2-840a-093b21473d9a@github.com>

On Tue, 29 Jun 2021 07:08:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> At the moment NMT prints a total of reserved and committed bytes. If one wants to know how much C-Heap the VM uses, one needs to add all numbers from the sub categories.
> 
> It would be helpful would NMT print the total number of malloced memory and additionally the malloc invocation count.
> 
> ----
> 
> This patch modifes the printout to print, in addition to totals, the number of malloced bytes, malloc invocation counts, and number of mmap reserved/committed bytes. This mirrors the way we print individual sub categories and allocation sites.
> 
> Before:
> 
> Native Memory Tracking:
> 
> Total: reserved=18489703KB, committed=1183967KB
> 
> 
> After:
> 
> 
> Native Memory Tracking:
> 
> Total: reserved=18491726KB, committed=1183178KB
>        malloc: 40590KB #13669
>        mmap:   reserved=18451136KB, committed=1142588KB
> 
> 
> Tests: Ran hotspot/runtime/NMT jtreg tests.

Good to me.

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4622

From kevinw at openjdk.java.net  Tue Jun 29 11:52:09 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 11:52:09 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v3]
In-Reply-To: <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
Message-ID: <7d4eUfnPx_xpdF2AbHyp6Kuzzg7ppyZesyXMusS7lDk=.2c96c78a-d3af-4684-b5c6-b5393c6a1ced@github.com>

On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use UINT64_FORMAT; change SA and test impl

Maybe we can't make everybody happy, but what we have now is a good improvement (for many/most).
I tested with the SA change, the test passes, and manually on Windows I ran jstack and jhsdb jstack, jhsdb clhsdb.

> Will it be too heavy to add a platform-dependent implementation for this small function?...
I think so.
I think this looks good now.

I don't think it's a change we should backport, or at least not quickly, out of concern for people/tools who might be parsing this output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Tue Jun 29 11:58:05 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 11:58:05 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
Message-ID: <qRB2g5KYyuj4BkMuCPfNzLjw7qwZ7XuQ7U_vm9OIQRQ=.07f81ef7-af54-4a7a-89b9-24da35976da1@github.com>

On Mon, 28 Jun 2021 07:46:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore cleanup code

src/hotspot/share/runtime/osThread.cpp line 41:

> 39: // Printing
> 40: void OSThread::print_on(outputStream *st) const {
> 41:   st->print("nid=%d ", thread_id());

Just update the (C) year above from 2019 to 2021.
JhsdbThreadInfoTest.java has it already in the latest revision.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Tue Jun 29 11:58:04 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 11:58:04 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v3]
In-Reply-To: <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
Message-ID: <LuRJLP3nn2T5CpSXkZQ6aBlwz5lZXNbyDtVC-FwRoQQ=.7afef0a9-672e-4564-a45a-7ecdbb364e48@github.com>

On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use UINT64_FORMAT; change SA and test impl

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Tue Jun 29 13:02:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 29 Jun 2021 13:02:03 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <nlaaEsNjq33PVFalYg8mOm9de6VI0Z4sDBPiD0ZDi68=.e12e3b6e-e382-47b2-840a-093b21473d9a@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
 <nlaaEsNjq33PVFalYg8mOm9de6VI0Z4sDBPiD0ZDi68=.e12e3b6e-e382-47b2-840a-093b21473d9a@github.com>
Message-ID: <V-MgS1U7rp_mTdpLSWGcw2DsiSfzDjTp817MTa9VzW4=.8852e233-fb0a-4113-b815-bea5bb6b1289@github.com>

On Tue, 29 Jun 2021 11:18:48 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the moment NMT prints a total of reserved and committed bytes. If one wants to know how much C-Heap the VM uses, one needs to add all numbers from the sub categories.
>> 
>> It would be helpful would NMT print the total number of malloced memory and additionally the malloc invocation count.
>> 
>> ----
>> 
>> This patch modifes the printout to print, in addition to totals, the number of malloced bytes, malloc invocation counts, and number of mmap reserved/committed bytes. This mirrors the way we print individual sub categories and allocation sites.
>> 
>> Before:
>> 
>> Native Memory Tracking:
>> 
>> Total: reserved=18489703KB, committed=1183967KB
>> 
>> 
>> After:
>> 
>> 
>> Native Memory Tracking:
>> 
>> Total: reserved=18491726KB, committed=1183178KB
>>        malloc: 40590KB #13669
>>        mmap:   reserved=18451136KB, committed=1142588KB
>> 
>> 
>> Tests: Ran hotspot/runtime/NMT jtreg tests.
>
> Good to me.

Thank you @zhengyu123

-------------

PR: https://git.openjdk.java.net/jdk/pull/4622

From coleenp at openjdk.java.net  Tue Jun 29 13:04:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 29 Jun 2021 13:04:05 GMT
Subject: RFR: 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
In-Reply-To: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
References: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
Message-ID: <u5HwCavQUsTNNvHEcs7gfyF4V6z24CMsC-3FKaes_SI=.4ad79703-03c9-4694-92e3-f564fbe73a81@github.com>

On Mon, 28 Jun 2021 16:18:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to test ParallelSuperTest.java. I only saw the timeout once on one of my GHA tests but the issue can be easily reproduced by adding a delay in startLoading() before the main thread tries to synchronize on thread_sync.
> Run the test with and without the added delay. The test times out without the patch and passes with the patch.
> 
> Thanks,
> Patricio

Thank you so much for fixing this! I guessed that the synchronization was dubious when I wrote the test but it seemed to do what I want wrt timing, so I left it.  That's how it got checked in.  Thanks for fixing it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4614

From jiefu at openjdk.java.net  Tue Jun 29 14:08:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 29 Jun 2021 14:08:00 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
Message-ID: <UxDmvNq-fHwbh63502XQ9KO85EOCp6-FXALv9xZtCcU=.9e6927f2-5b87-4af3-8de1-9c1e6b6fd3e4@github.com>

On Sun, 20 Jun 2021 09:52:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch which:
>  1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
>  2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`
> 
> Testing:
>   - Linux/x64, MacOS/x64
> 
> Thanks.
> Best regards,
> Jie

@iignatev and @tstuefe , are you fine with this change?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/104

From stuefe at openjdk.java.net  Tue Jun 29 14:14:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 29 Jun 2021 14:14:03 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
Message-ID: <qN_cbNP_npdLzqUNq5PstUdDOlpsnxBp9__qOda5TTM=.d415dbd8-edb5-496f-80ab-9c5e2dd0841e@github.com>

On Sun, 20 Jun 2021 09:52:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch which:
>  1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
>  2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`
> 
> Testing:
>   - Linux/x64, MacOS/x64
> 
> Thanks.
> Best regards,
> Jie

LGTM

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/104

From pchilanomate at openjdk.java.net  Tue Jun 29 14:39:05 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Tue, 29 Jun 2021 14:39:05 GMT
Subject: RFR: 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
In-Reply-To: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
References: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
Message-ID: <CtzSLVBatKLt-kLNfCqLfAPEjkmvP2ijyBU7F0qVOr0=.4a43239b-752d-4dcd-a34b-df2b4f9748ac@github.com>

On Mon, 28 Jun 2021 16:18:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to test ParallelSuperTest.java. I only saw the timeout once on one of my GHA tests but the issue can be easily reproduced by adding a delay in startLoading() before the main thread tries to synchronize on thread_sync.
> Run the test with and without the added delay. The test times out without the patch and passes with the patch.
> 
> Thanks,
> Patricio

Thanks David and Coleen for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4614

From pchilanomate at openjdk.java.net  Tue Jun 29 14:39:05 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Tue, 29 Jun 2021 14:39:05 GMT
Subject: Integrated: 8269530: runtime/ParallelLoad/ParallelSuperTest.java
 timeout
In-Reply-To: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
References: <Dsu7FZ0DdwADNG7qP0FCyggb8RTY54qGLkeWrcvPrHQ=.c590e491-7f14-4bc3-8fc3-c7178df9a9a7@github.com>
Message-ID: <bxE8ZFiNc64CfT_s9msgQJmZcTdV_T4mmD7AE7YmMlo=.68dc0461-3382-4b89-9969-df2fc93e1a3f@github.com>

On Mon, 28 Jun 2021 16:18:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to test ParallelSuperTest.java. I only saw the timeout once on one of my GHA tests but the issue can be easily reproduced by adding a delay in startLoading() before the main thread tries to synchronize on thread_sync.
> Run the test with and without the added delay. The test times out without the patch and passes with the patch.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: e238cbd5
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e238cbd596d29d10e45e4bad7a10708c4022097f
Stats:     22 lines in 2 files changed: 4 ins; 4 del; 14 mod

8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/4614

From iignatyev at openjdk.java.net  Tue Jun 29 15:39:05 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 29 Jun 2021 15:39:05 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <UxDmvNq-fHwbh63502XQ9KO85EOCp6-FXALv9xZtCcU=.9e6927f2-5b87-4af3-8de1-9c1e6b6fd3e4@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
 <UxDmvNq-fHwbh63502XQ9KO85EOCp6-FXALv9xZtCcU=.9e6927f2-5b87-4af3-8de1-9c1e6b6fd3e4@github.com>
Message-ID: <fddc6wmkymGDEu3Thf3vpuKfmkA_Yd-ZqNA8wFiAR_0=.aea53a29-c0a4-41fb-b898-6429bca63e24@github.com>

On Tue, 29 Jun 2021 14:04:40 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this patch which:
>>  1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
>>  2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`
>> 
>> Testing:
>>   - Linux/x64, MacOS/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> @iignatev and @tstuefe , are you fine with this change?
> Thanks.

Hi @DamonFool ,

sorry I was on vacation and missed this PR.

in general it looks ok, but I can't help but wonder why have you replaced `-XX:MaxMetaspaceSize=8m` w/ `-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=20m`; won't removing `-Xmx` and adding `-XX:MaxRAMPercentage=25` be sufficient?

Thanks,
-- Igor

-------------

PR: https://git.openjdk.java.net/jdk17/pull/104

From kvn at openjdk.java.net  Tue Jun 29 16:05:01 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Jun 2021 16:05:01 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file
In-Reply-To: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
Message-ID: <zKdRUq-wMSDlMpyGJi8CVa0GksZwa0s9R0LF4DcUQ7Q=.eed17c0c-5bb9-4a3f-b150-d45bc544cf79@github.com>

On Mon, 28 Jun 2021 22:58:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
> 
> For example:
> 
>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
> #  fatal error: thread 41219: Fatal error in JVMCI shared library
> #
> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
> #
> # The JVMCI shared library error data is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

Someone from Runtime group may have good suggestions for this changes.
I think you need to follow (or create JVMCI specific flags) flags used for error reporting:

SuppressFatalErrorMessage
ShowMessageBoxOnError
UseOSErrorReporting
ErrorFileToStdout
ErrorFileToStderr

src/hotspot/share/utilities/vmError.cpp line 1592:

> 1590: #if INCLUDE_JVMCI
> 1591:   if (JVMCI::fatal_log_filename() != NULL) {
> 1592:     out.print_raw("#\n# The JVMCI shared library error data is saved as:\n# ");

I prefer `report file` instead of `data`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4620

From zgu at openjdk.java.net  Tue Jun 29 16:09:20 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 29 Jun 2021 16:09:20 GMT
Subject: [jdk17] RFR: 8269594: assert(_handle_mark_nesting > 1) failed: memory
 leak: allocating handle outside HandleMark
Message-ID: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>

I would like to fix this assertion in jdk17. It was caught in Shenandoah nightly test and hard to reproduce, but fix is simple and low risk.

-------------

Commit messages:
 - v0

Changes: https://git.openjdk.java.net/jdk17/pull/173/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=173&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269594
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/173/head:pull/173

PR: https://git.openjdk.java.net/jdk17/pull/173

From iklam at openjdk.java.net  Tue Jun 29 17:41:00 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 29 Jun 2021 17:41:00 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
Message-ID: <2K0O-KWljzngKvevO2hEK_aOi0Yqt9SOffnkKa548us=.fddc4b3d-af98-4c72-88a6-3009cd03b4e2@github.com>

On Mon, 28 Jun 2021 23:40:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
>> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
>> 
>> Testing: 
>> - [x] tiers 1,2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use st->print_raw_cr() on all lengths of class path

LGTM

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4616

From iklam at openjdk.java.net  Tue Jun 29 17:47:05 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 29 Jun 2021 17:47:05 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
Message-ID: <UvzzlCwn9BOfyiPD-JrBzlLHpRpors6noBK9uI_XMVI=.9912d2ca-0e24-4cd7-8bd1-d77591668641@github.com>

On Mon, 28 Jun 2021 23:40:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
>> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
>> 
>> Testing: 
>> - [x] tiers 1,2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use st->print_raw_cr() on all lengths of class path

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From ccheung at openjdk.java.net  Tue Jun 29 17:54:40 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 17:54:40 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v4]
In-Reply-To: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
Message-ID: <KM5XzdfZgS_C7MbCKdfqUlHypPLIRVkuf1awqdyjJGI=.84762f7b-0af5-4b8f-8943-902ba3be9e01@github.com>

> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
> 
> Testing: 
> - [x] tiers 1,2.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  add a comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4616/files
  - new: https://git.openjdk.java.net/jdk/pull/4616/files/b4b645cd..52f75f05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4616&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4616/head:pull/4616

PR: https://git.openjdk.java.net/jdk/pull/4616

From ccheung at openjdk.java.net  Tue Jun 29 18:01:19 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 18:01:19 GMT
Subject: RFR: 8263640: hs_err improvement: handle class path longer than
 O_BUFLEN [v3]
In-Reply-To: <UvzzlCwn9BOfyiPD-JrBzlLHpRpors6noBK9uI_XMVI=.9912d2ca-0e24-4cd7-8bd1-d77591668641@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
 <gOGzHQRLt-WGNLd3zhmH0VW4VjkbY6QibdD7BLfGPik=.6ccacda7-086a-43db-a140-aaa28a9e89cb@github.com>
 <UvzzlCwn9BOfyiPD-JrBzlLHpRpors6noBK9uI_XMVI=.9912d2ca-0e24-4cd7-8bd1-d77591668641@github.com>
Message-ID: <eIS4RSNMRBnW-If0ov-8ULSBd-MXfXJ4phyA7RaROvs=.828b2fc1-a413-4850-b3da-8c6883ca5221@github.com>

On Tue, 29 Jun 2021 17:44:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use st->print_raw_cr() on all lengths of class path
>
> Marked as reviewed by iklam (Reviewer).

@iklam, @dholmes-ora, @yminqi Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From ccheung at openjdk.java.net  Tue Jun 29 18:01:22 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 18:01:22 GMT
Subject: Integrated: 8263640: hs_err improvement: handle class path longer
 than O_BUFLEN
In-Reply-To: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
References: <fnNjsEZrPGnNMyIHmipad-9FQIwUvVMEeFy5SNuQxog=.b52caef3-8651-45c2-b98b-b0d41192eeb9@github.com>
Message-ID: <wh2Z25rR99N21_SGy7rm8diTql44G3XQE_76T3uQnGk=.4513048e-da24-4931-970a-9249788cd5be@github.com>

On Mon, 28 Jun 2021 18:57:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for handling the printing of class path with length longer than O_BUFLEN.
> The bug is also reproducible using the `jcmd VM.command_line`. The new test uses `jcmd` to verify this change.
> 
> Testing: 
> - [x] tiers 1,2.

This pull request has now been integrated.

Changeset: c1e2a294
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c1e2a29448b67bfe90f99252feef7ffc282b05b2
Stats:     89 lines in 2 files changed: 88 ins; 0 del; 1 mod

8263640: hs_err improvement: handle class path longer than O_BUFLEN

Reviewed-by: iklam, minqi, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4616

From coleenp at openjdk.java.net  Tue Jun 29 18:45:01 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 29 Jun 2021 18:45:01 GMT
Subject: [jdk17] RFR: 8269594: assert(_handle_mark_nesting > 1) failed:
 memory leak: allocating handle outside HandleMark
In-Reply-To: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
References: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
Message-ID: <NYiuSq7o_phBQSp4Vv43nVLiYsQw3ADKaQSLjnj9g9M=.39ee43ba-ee30-49b3-ac04-6c5aca722676@github.com>

On Tue, 29 Jun 2021 16:02:53 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to fix this assertion in jdk17. It was caught in Shenandoah nightly test and hard to reproduce, but fix is simple and low risk.

This looks good.  I think it's worth fixing because the Handles could leak without this assert in production, and that could be really hard to diagnose.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/173

From naoto at openjdk.java.net  Tue Jun 29 19:29:04 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 29 Jun 2021 19:29:04 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform
In-Reply-To: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
Message-ID: <pw_h06tc543T0y4KWDzX6w9hikvWAPEoNYrVaFVgbNU=.c6f6338a-637e-4cbf-a88a-7f5c9fa967b1@github.com>

On Fri, 25 Jun 2021 12:10:18 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Hi all,
> 
> Could you please review the 8269373 bug fixes?
> 
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

>From a peek at the bug report, I could not find out the exact cause why they are failing. Have you figured it out?

As to the fix itself, I would rather avoid hardcoding `en-US` in the argument. Would that be replaced with the launching process' locale?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4594

From jvernee at openjdk.java.net  Tue Jun 29 19:31:12 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 29 Jun 2021 19:31:12 GMT
Subject: [jdk17] RFR: 8269594: assert(_handle_mark_nesting > 1) failed:
 memory leak: allocating handle outside HandleMark
In-Reply-To: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
References: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
Message-ID: <xmD2c70sUWCcvOM6SRCAiHYHA3dl17y203Myynp1FQ4=.3e55be8a-1054-4ee8-b8e6-97979f44437f@github.com>

On Tue, 29 Jun 2021 16:02:53 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to fix this assertion in jdk17. It was caught in Shenandoah nightly test and hard to reproduce, but fix is simple and low risk.

Looks good to me as well. I also ran into this assert while working on #149 [1]

[1] : https://github.com/openjdk/jdk17/pull/149/files#diff-d61020d12394708828d066d097d823180c01b74d35d4c3e369aead062abc11efR931

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/173

From ccheung at openjdk.java.net  Tue Jun 29 19:46:18 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 19:46:18 GMT
Subject: RFR: 8269615: Fix for 8263640 broke Windows build
Message-ID: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>

Please review this trivial change for fixing build failure on Windows.

Testing:

- [x] windows-x64-debug build
- [x] tier1 (in progress)

-------------

Commit messages:
 - 8269615: Fix for 8263640 broke Windows build

Changes: https://git.openjdk.java.net/jdk/pull/4626/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4626&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269615
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4626.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4626/head:pull/4626

PR: https://git.openjdk.java.net/jdk/pull/4626

From dcubed at openjdk.java.net  Tue Jun 29 19:58:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 29 Jun 2021 19:58:02 GMT
Subject: RFR: 8269615: Fix for 8263640 broke Windows build
In-Reply-To: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
References: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
Message-ID: <aLL87CjZzngAX9MXB4YPFQvaA7Y8BgicOgpfQjaGtgo=.b53f71b5-c1c2-474e-9306-83a1b4ce81b7@github.com>

On Tue, 29 Jun 2021 19:39:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this trivial change for fixing build failure on Windows.
> 
> Testing:
> 
> - [x] windows-x64-debug build
> - [x] tier1 (in progress)

Thumbs up.

This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4626

From mikael at openjdk.java.net  Tue Jun 29 19:58:02 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Tue, 29 Jun 2021 19:58:02 GMT
Subject: RFR: 8269615: Fix for 8263640 broke Windows build
In-Reply-To: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
References: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
Message-ID: <1btRviQNj_OksTHF1Oo85LoeMYUdl36jGV5ApV-s69w=.37e5c18c-4bc8-48ec-bdb5-d8b2c4a69463@github.com>

On Tue, 29 Jun 2021 19:39:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this trivial change for fixing build failure on Windows.
> 
> Testing:
> 
> - [x] windows-x64-debug build
> - [x] tier1 (in progress)

Marked as reviewed by mikael (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 1119:

> 1117:       st->print_raw_cr("<not set>");
> 1118:     } else {
> 1119:       st->print_raw_cr(path, (int)len);

This seems like a reasonable fix.

As a potential follow-up change: I can't help but notice that outputStream::print_raw_cr just delegates to outputStream::write, which takes a size_t argument, so maybe we should align the types?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4626

From iklam at openjdk.java.net  Tue Jun 29 19:58:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 29 Jun 2021 19:58:02 GMT
Subject: RFR: 8269615: Fix for 8263640 broke Windows build
In-Reply-To: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
References: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
Message-ID: <-9NAIPVUeljbe5mJeWXYKGKyvmRR1oG7ANpKSKEwkQU=.baff1b5e-20fb-42e9-9341-000cd4e4b9d8@github.com>

On Tue, 29 Jun 2021 19:39:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this trivial change for fixing build failure on Windows.
> 
> Testing:
> 
> - [x] windows-x64-debug build
> - [x] tier1 (in progress)

LGTM and trivial.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4626

From ccheung at openjdk.java.net  Tue Jun 29 19:58:03 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 19:58:03 GMT
Subject: RFR: 8269615: Fix for 8263640 broke Windows build
In-Reply-To: <-9NAIPVUeljbe5mJeWXYKGKyvmRR1oG7ANpKSKEwkQU=.baff1b5e-20fb-42e9-9341-000cd4e4b9d8@github.com>
References: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
 <-9NAIPVUeljbe5mJeWXYKGKyvmRR1oG7ANpKSKEwkQU=.baff1b5e-20fb-42e9-9341-000cd4e4b9d8@github.com>
Message-ID: <3qabMTrFLbg30C5WhK_wsj_PVTx58LyC2Lxccf9eC6U=.ea62f1ce-8da5-43fd-9c32-bf2b3e95dea8@github.com>

On Tue, 29 Jun 2021 19:47:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this trivial change for fixing build failure on Windows.
>> 
>> Testing:
>> 
>> - [x] windows-x64-debug build
>> - [x] tier1 (in progress)
>
> LGTM and trivial.

@iklam, @dcubed-ojdk Thanks for the quick review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4626

From ccheung at openjdk.java.net  Tue Jun 29 19:58:03 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 19:58:03 GMT
Subject: RFR: 8269615: Fix for 8263640 broke Windows build
In-Reply-To: <1btRviQNj_OksTHF1Oo85LoeMYUdl36jGV5ApV-s69w=.37e5c18c-4bc8-48ec-bdb5-d8b2c4a69463@github.com>
References: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
 <1btRviQNj_OksTHF1Oo85LoeMYUdl36jGV5ApV-s69w=.37e5c18c-4bc8-48ec-bdb5-d8b2c4a69463@github.com>
Message-ID: <b9r-qvp-6KzNMkr23mTs1VSbK775BYy_Zq7s-AthtlE=.d12260e6-98be-4474-b938-22ff1ed5fac3@github.com>

On Tue, 29 Jun 2021 19:53:25 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Please review this trivial change for fixing build failure on Windows.
>> 
>> Testing:
>> 
>> - [x] windows-x64-debug build
>> - [x] tier1 (in progress)
>
> src/hotspot/share/runtime/arguments.cpp line 1119:
> 
>> 1117:       st->print_raw_cr("<not set>");
>> 1118:     } else {
>> 1119:       st->print_raw_cr(path, (int)len);
> 
> This seems like a reasonable fix.
> 
> As a potential follow-up change: I can't help but notice that outputStream::print_raw_cr just delegates to outputStream::write, which takes a size_t argument, so maybe we should align the types?

Or change the second parameter of print_raw() and print_raw_cr() to size_t?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4626

From ccheung at openjdk.java.net  Tue Jun 29 19:58:04 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 29 Jun 2021 19:58:04 GMT
Subject: Integrated: 8269615: Fix for 8263640 broke Windows build
In-Reply-To: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
References: <WGwP8cBwinDeBIsEwJrRRCfP7tqcVgYu3SpeWDofQOU=.f1f29581-4d5b-4e59-9088-c7d0a5547f1a@github.com>
Message-ID: <-wch8IpjLtToMmlWBFSeD8cNs4jnCMwzPJtQKr9QGCA=.64fdccc1-2a3d-4754-acde-4337309d98d4@github.com>

On Tue, 29 Jun 2021 19:39:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this trivial change for fixing build failure on Windows.
> 
> Testing:
> 
> - [x] windows-x64-debug build
> - [x] tier1 (in progress)

This pull request has now been integrated.

Changeset: 1ac8deef
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1ac8deef4c0973eeeef2a34f6d0cee0c2efa82a9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269615: Fix for 8263640 broke Windows build

Reviewed-by: iklam, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/4626

From xliu at openjdk.java.net  Tue Jun 29 20:14:05 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 29 Jun 2021 20:14:05 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
Message-ID: <myy-5JmQi94G-wDP1Cq1U-LLdiSa49-3m9vPnoPWKuk=.d41161b5-45e4-4aab-ba82-780395729f95@github.com>

On Tue, 29 Jun 2021 07:08:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> At the moment NMT prints a total of reserved and committed bytes. If one wants to know how much C-Heap the VM uses, one needs to add all numbers from the sub categories.
> 
> It would be helpful would NMT print the total number of malloced memory and additionally the malloc invocation count.
> 
> ----
> 
> This patch modifes the printout to print, in addition to totals, the number of malloced bytes, malloc invocation counts, and number of mmap reserved/committed bytes. This mirrors the way we print individual sub categories and allocation sites.
> 
> Before:
> 
> Native Memory Tracking:
> 
> Total: reserved=18489703KB, committed=1183967KB
> 
> 
> After:
> 
> 
> Native Memory Tracking:
> 
> Total: reserved=18491726KB, committed=1183178KB
>        malloc: 40590KB #13669
>        mmap:   reserved=18451136KB, committed=1142588KB
> 
> 
> Tests: Ran hotspot/runtime/NMT jtreg tests.

your change looks good to me. 

>        malloc: 40590KB #13669
I think 13669 is the invocation count of malloc(). Out of curiosity, may I know how to use it?  Do you intend to use this to pinpoint memleak from malloc()?  A straight malloc() icount may not help much. Is it possible we can have the number of  unbalanced malloc()?  That is icount of malloc() minus icount of free(). of course, it is not directly related to this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4622

From xliu at openjdk.java.net  Tue Jun 29 20:19:02 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 29 Jun 2021 20:19:02 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
Message-ID: <W3TGwQc8mIQqdk5AVHrDH7ok_saX1R1UFMDxvMCA1gM=.e3ab37e5-75a0-4a8d-8db8-7202e7c15d89@github.com>

On Tue, 29 Jun 2021 07:08:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> At the moment NMT prints a total of reserved and committed bytes. If one wants to know how much C-Heap the VM uses, one needs to add all numbers from the sub categories.
> 
> It would be helpful would NMT print the total number of malloced memory and additionally the malloc invocation count.
> 
> ----
> 
> This patch modifes the printout to print, in addition to totals, the number of malloced bytes, malloc invocation counts, and number of mmap reserved/committed bytes. This mirrors the way we print individual sub categories and allocation sites.
> 
> Before:
> 
> Native Memory Tracking:
> 
> Total: reserved=18489703KB, committed=1183967KB
> 
> 
> After:
> 
> 
> Native Memory Tracking:
> 
> Total: reserved=18491726KB, committed=1183178KB
>        malloc: 40590KB #13669
>        mmap:   reserved=18451136KB, committed=1142588KB
> 
> 
> Tests: Ran hotspot/runtime/NMT jtreg tests.

Marked as reviewed by xliu (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4622

From david.holmes at oracle.com  Tue Jun 29 20:53:05 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Jun 2021 06:53:05 +1000
Subject: Confusion about stack map verify of constructors
In-Reply-To: <tencent_A12602702043AD722D2BC68C9AC929C77206@qq.com>
References: <tencent_A12602702043AD722D2BC68C9AC929C77206@qq.com>
Message-ID: <c56d06fa-b7d7-a150-c3ca-0e868ff93954@oracle.com>

Hi,

On 29/06/2021 5:57 pm, NekoCaffeine wrote:
> Hi everyone,
> 
> 
> When a super constructor is called in a TryCatchBlock,
> &nbsp;none of the following exception handler locals will pass validation,
> &nbsp;uninitializedThis, referenceName, TOP, <empty&gt;, java/lang/Object.

This is a deliberate design decision in the language. You are not 
allowed to put a super constructor call in a try/catch because it would 
result in partially constructed objects. If you super constructor fails 
by throwing an exception then your constructor must also fail by 
throwing the exception.

Cheers,
David

> 
> Where uninitializedThis and referenceName are mutually exclusive,
> &nbsp;and either one will fail because it does not contain the other.
> TOP will fail because it is not compatible with the flags of uninitializedThis.
> <empty&gt; will fail for incompatibility with uninitializedThis.
> 
> 
> Is there a stackframe that passes validation?
> 
> 
> Thanks in advance,
> NekoCaffeine
> 

From dnsimon at openjdk.java.net  Tue Jun 29 21:14:03 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 29 Jun 2021 21:14:03 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file
In-Reply-To: <zKdRUq-wMSDlMpyGJi8CVa0GksZwa0s9R0LF4DcUQ7Q=.eed17c0c-5bb9-4a3f-b150-d45bc544cf79@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
 <zKdRUq-wMSDlMpyGJi8CVa0GksZwa0s9R0LF4DcUQ7Q=.eed17c0c-5bb9-4a3f-b150-d45bc544cf79@github.com>
Message-ID: <MIRxqMF_YYeSLNG2volN25NZtKt6JDslLi8wcsEgd7s=.1dde4bd0-f696-4c49-b1e7-2439d26637a6@github.com>

On Tue, 29 Jun 2021 16:02:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Someone from Runtime group may have good suggestions for this changes.
> I think you need to follow (or create JVMCI specific flags) flags used for error reporting:
> 
> SuppressFatalErrorMessage

I don't think extra handling is needed for that flag. It cuts off all paths that lead to libjvmci error handling.

> ErrorFileToStdout
> ErrorFileToStderr

I will push a change to respect these flags in `JVMCI::fatal_log`.

> ShowMessageBoxOnError
> UseOSErrorReporting

It's not clear to me that I need to worry about these - advice welcome.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4620

From dnsimon at openjdk.java.net  Tue Jun 29 21:43:32 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 29 Jun 2021 21:43:32 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v2]
In-Reply-To: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
Message-ID: <6EJyr_Jao1QuTa5NE-Ub_TLBezK82p1ucUzH3DjfLOs=.803cfe50-f086-4355-b062-72763f8d935d@github.com>

> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
> 
> For example:
> 
>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
> #  fatal error: thread 41219: Fatal error in JVMCI shared library
> #
> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
> #
> # The JVMCI shared library error data is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  respect ErrorFileToStdout and ErrorFileToStderr flags

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4620/files
  - new: https://git.openjdk.java.net/jdk/pull/4620/files/1720090f..fbeaedef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=00-01

  Stats: 16 lines in 2 files changed: 7 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4620/head:pull/4620

PR: https://git.openjdk.java.net/jdk/pull/4620

From dnsimon at openjdk.java.net  Tue Jun 29 21:54:30 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 29 Jun 2021 21:54:30 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v3]
In-Reply-To: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
Message-ID: <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>

> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
> 
> For example:
> 
>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
> #  fatal error: thread 41219: Fatal error in JVMCI shared library
> #
> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
> #
> # The JVMCI shared library error data is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  respect ErrorFileToStdout and ErrorFileToStderr flags

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4620/files
  - new: https://git.openjdk.java.net/jdk/pull/4620/files/fbeaedef..ba004ef0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4620/head:pull/4620

PR: https://git.openjdk.java.net/jdk/pull/4620

From kvn at openjdk.java.net  Tue Jun 29 22:18:02 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Jun 2021 22:18:02 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v3]
In-Reply-To: <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
 <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
Message-ID: <r8gGOI8hoZN4Qlf3Mit6w-7gGglXSym54mRnlSi9ozw=.087ffd7c-fdee-4947-94ff-30249d1c9fa2@github.com>

On Tue, 29 Jun 2021 21:54:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
>> 
>> For example:
>> 
>>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
>> #  fatal error: thread 41219: Fatal error in JVMCI shared library
>> #
>> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
>> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
>> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
>> #
>> # The JVMCI shared library error data is saved as:
>> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>
> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Okay. this is fine.

Still you need review from Runtime group. I will ping them.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4620

From dholmes at openjdk.java.net  Tue Jun 29 22:30:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 22:30:02 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v3]
In-Reply-To: <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
 <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
Message-ID: <drsLO5HUIpkjjqllFXVxXtIp6RuMsESyQIdiYi-Mrvk=.852c3f97-1d00-43b2-8af0-1b3a0e167e89@github.com>

On Tue, 29 Jun 2021 21:54:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
>> 
>> For example:
>> 
>>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
>> #  fatal error: thread 41219: Fatal error in JVMCI shared library
>> #
>> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
>> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
>> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
>> #
>> # The JVMCI shared library error data is saved as:
>> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>
> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Personally I think JVMCI error reporting can be handled independently of the other VM error reporting flags etc. No need to interact with ErrorFileToStdOut/Err as this is not the error file that flag refers to.

I will take a look at the changes in more detail.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4620

From dholmes at openjdk.java.net  Tue Jun 29 22:33:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 22:33:21 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
Message-ID: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>

Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.

This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.

The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.

A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).

The trickiest changes related to the CompilerThreads, so they need particular scrutiny.

Testing: tiers 1-3

Thanks,
David

-------------

Commit messages:
 - Removed leftover experimental code
 - Remove unnedded include
 - Fixed old comment
 - Set native priority before starting the CompilerThread.
 - 8269466: Factor out the common code for initializing and starting internal VM JavaThreads
 - interim 2 - template method doesn't work
 - Interim

Changes: https://git.openjdk.java.net/jdk/pull/4629/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269466
  Stats: 278 lines in 13 files changed: 63 ins; 140 del; 75 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629

PR: https://git.openjdk.java.net/jdk/pull/4629

From david.holmes at oracle.com  Tue Jun 29 22:37:21 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Jun 2021 08:37:21 +1000
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <0dfe8a38-b2cb-8e4e-1e4e-6c3a556ce13e@oracle.com>

And apologies for the old commits - I forgot to clear them out before 
creating the PR.

David

On 30/06/2021 8:33 am, David Holmes wrote:
> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David
> 
> -------------
> 
> Commit messages:
>   - Removed leftover experimental code
>   - Remove unnedded include
>   - Fixed old comment
>   - Set native priority before starting the CompilerThread.
>   - 8269466: Factor out the common code for initializing and starting internal VM JavaThreads
>   - interim 2 - template method doesn't work
>   - Interim
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4629/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8269466
>    Stats: 278 lines in 13 files changed: 63 ins; 140 del; 75 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4629.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629
> 
> PR: https://git.openjdk.java.net/jdk/pull/4629
> 

From dholmes at openjdk.java.net  Tue Jun 29 23:23:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 23:23:04 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v3]
In-Reply-To: <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
 <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
Message-ID: <4mDVlXQ8lFRejMqk7zhF-vCGkTplVPlBKHu2qb9Sezo=.72fc6f41-e55e-41fe-ba13-7f7b683b04a8@github.com>

On Tue, 29 Jun 2021 21:54:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
>> 
>> For example:
>> 
>>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
>> #  fatal error: thread 41219: Fatal error in JVMCI shared library
>> #
>> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
>> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
>> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
>> #
>> # The JVMCI shared library error data is saved as:
>> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>
> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

This is predominantly a compiler change so I can only approve the shared runtime changes in vmError.

I have no concerns about this change from a runtime perspective.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4620

From iignatyev at openjdk.java.net  Tue Jun 29 23:31:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 29 Jun 2021 23:31:02 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
Message-ID: <gCvqhS8jYPOFQph7Wvl5GqlwBaS8XrFyTPHhKis5eSU=.596ad0d2-659b-460e-8495-0ac5974d7bf3@github.com>

On Sun, 20 Jun 2021 09:52:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch which:
>  1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
>  2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`
> 
> Testing:
>   - Linux/x64, MacOS/x64
> 
> Thanks.
> Best regards,
> Jie

I see, I was comparing it w/ the prev. revision.
LGTM.

-------------

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/104

From jiefu at openjdk.java.net  Tue Jun 29 23:31:02 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 29 Jun 2021 23:31:02 GMT
Subject: [jdk17] RFR: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <fddc6wmkymGDEu3Thf3vpuKfmkA_Yd-ZqNA8wFiAR_0=.aea53a29-c0a4-41fb-b898-6429bca63e24@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
 <UxDmvNq-fHwbh63502XQ9KO85EOCp6-FXALv9xZtCcU=.9e6927f2-5b87-4af3-8de1-9c1e6b6fd3e4@github.com>
 <fddc6wmkymGDEu3Thf3vpuKfmkA_Yd-ZqNA8wFiAR_0=.aea53a29-c0a4-41fb-b898-6429bca63e24@github.com>
Message-ID: <GyUNIquBLe-j5JPU1A-c2YLHdJxWTZOIXqqefn6LMy0=.54ef621b-b98d-405b-ae63-27a5670f3227@github.com>

On Tue, 29 Jun 2021 15:36:24 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> in general it looks ok, but I can't help but wonder why have you replaced `-XX:MaxMetaspaceSize=8m` w/ `-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=20m`; won't removing `-Xmx` and adding `-XX:MaxRAMPercentage=25` be sufficient?

Thanks @tstuefe and @iignatev for your review.

This is because the original test uses `-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=20m` [1] .
To lower the risk, only `-XX:MaxRAMPercentage=25` is added compared with the original code.

Thanks.

[1] https://github.com/openjdk/jdk16u/blob/master/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java#L39

-------------

PR: https://git.openjdk.java.net/jdk17/pull/104

From sspitsyn at openjdk.java.net  Wed Jun 30 01:04:00 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 30 Jun 2021 01:04:00 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <LnORBf1Jp2uZzPilWV_3F95ycKV5Szgwx7uV-QsL1kw=.4698c756-7f6e-4384-ab1a-90df9fcd3233@github.com>

On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

Hi David,
This looks good to me.
Some copyright comments need update.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From jiefu at openjdk.java.net  Wed Jun 30 01:29:02 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 30 Jun 2021 01:29:02 GMT
Subject: [jdk17] Integrated: 8269065: [REDO]
 vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with
 OutOfMemoryError
In-Reply-To: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
References: <Cz1Opq76cLNrzWIoLYIFL-evWMfPyM-P_gUzzVvOoP8=.24d6eaa2-1d65-4240-85c2-cc8bba1107c5@github.com>
Message-ID: <WwxDvBxgQQEG4NLZjPoaCgGv9AIr7-irJ2ZgYJEGfg8=.c4052431-1512-4d2a-9845-859dc1d2e00d@github.com>

On Sun, 20 Jun 2021 09:52:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch which:
>  1) Restore vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
>  2) Fix the OOME by adding `-XX:MaxRAMPercentage=25`
> 
> Testing:
>   - Linux/x64, MacOS/x64
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: a661686e
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/a661686e1e709143438a37c761a9c12e0b98eaa5
Stats:     56 lines in 1 file changed: 38 ins; 6 del; 12 mod

8269065: [REDO] vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError

Reviewed-by: stuefe, iignatyev

-------------

PR: https://git.openjdk.java.net/jdk17/pull/104

From dholmes at openjdk.java.net  Wed Jun 30 01:31:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 01:31:30 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>

> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed copyright years in hpp files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4629/files
  - new: https://git.openjdk.java.net/jdk/pull/4629/files/d4755137..e547e0a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629

PR: https://git.openjdk.java.net/jdk/pull/4629

From dholmes at openjdk.java.net  Wed Jun 30 01:34:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 01:34:00 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <ktSJPhE_5UlghFu191ZwCGqrexf_cBnJNhz_bbrye-o=.d83c7a62-7b6e-4329-ae20-c2177f316d5f@github.com>

On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

Thanks for the review Serguei!

Copyright notices fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From yyang at openjdk.java.net  Wed Jun 30 02:43:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 02:43:30 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <qRB2g5KYyuj4BkMuCPfNzLjw7qwZ7XuQ7U_vm9OIQRQ=.07f81ef7-af54-4a7a-89b9-24da35976da1@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
 <qRB2g5KYyuj4BkMuCPfNzLjw7qwZ7XuQ7U_vm9OIQRQ=.07f81ef7-af54-4a7a-89b9-24da35976da1@github.com>
Message-ID: <xRYWxfmFRJbltO3vrBwz-LSGc9uTUllk8ioYwRHlvdA=.efa091e9-cc30-40f8-81e3-f7dae1cd28ac@github.com>

On Tue, 29 Jun 2021 11:54:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore cleanup code
>
> src/hotspot/share/runtime/osThread.cpp line 41:
> 
>> 39: // Printing
>> 40: void OSThread::print_on(outputStream *st) const {
>> 41:   st->print("nid=%d ", thread_id());
> 
> Just update the (C) year above from 2019 to 2021.
> JhsdbThreadInfoTest.java has it already in the latest revision.

Updated in both osThread.cpp and test file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 02:43:29 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 02:43:29 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  update copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/0f230755..6d3d0523

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Wed Jun 30 04:41:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 30 Jun 2021 04:41:03 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <myy-5JmQi94G-wDP1Cq1U-LLdiSa49-3m9vPnoPWKuk=.d41161b5-45e4-4aab-ba82-780395729f95@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
 <myy-5JmQi94G-wDP1Cq1U-LLdiSa49-3m9vPnoPWKuk=.d41161b5-45e4-4aab-ba82-780395729f95@github.com>
Message-ID: <9Lob0jf8Oldn3uY87mP75Il7WB6yTg9Dzz9lywMTtn0=.acf9e8fd-e3a8-4f4a-8339-4b15e72c6650@github.com>

On Tue, 29 Jun 2021 20:11:08 GMT, Xin Liu <xliu at openjdk.org> wrote:

> your change looks good to me.
> 

Thanks!

> > ```
> >    malloc: 40590KB #13669
> > ```
> 
> I think 13669 is the invocation count of malloc(). Out of curiosity, may I know how to use it? Do you intend to use this to pinpoint memleak from malloc()? A straight malloc() icount may not help much. Is it possible we can have the number of unbalanced malloc()? That is icount of malloc() minus icount of free(). of course, it is not directly related to this PR.

That count is not the invocation counter (which can be useful too under certain conditions) but the number of outstanding allocations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4622

From stuefe at openjdk.java.net  Wed Jun 30 04:41:04 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 30 Jun 2021 04:41:04 GMT
Subject: Integrated: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
Message-ID: <Q6kLJy6rUc4Tac2-WT32FvDnCQSVP9a3s8AI5w4HnpI=.66430ac8-42ff-46b0-b3dc-fa4c08196a64@github.com>

On Tue, 29 Jun 2021 07:08:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> At the moment NMT prints a total of reserved and committed bytes. If one wants to know how much C-Heap the VM uses, one needs to add all numbers from the sub categories.
> 
> It would be helpful would NMT print the total number of malloced memory and additionally the malloc invocation count.
> 
> ----
> 
> This patch modifes the printout to print, in addition to totals, the number of malloced bytes, malloc invocation counts, and number of mmap reserved/committed bytes. This mirrors the way we print individual sub categories and allocation sites.
> 
> Before:
> 
> Native Memory Tracking:
> 
> Total: reserved=18489703KB, committed=1183967KB
> 
> 
> After:
> 
> 
> Native Memory Tracking:
> 
> Total: reserved=18491726KB, committed=1183178KB
>        malloc: 40590KB #13669
>        mmap:   reserved=18451136KB, committed=1142588KB
> 
> 
> Tests: Ran hotspot/runtime/NMT jtreg tests.

This pull request has now been integrated.

Changeset: 3ad20fcd
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3ad20fcdfa35796c190ccbaf26872b0fe30d8c76
Stats:     25 lines in 3 files changed: 20 ins; 0 del; 5 mod

8269571: NMT should print total malloc bytes and invocation count

Reviewed-by: zgu, xliu

-------------

PR: https://git.openjdk.java.net/jdk/pull/4622

From stuefe at openjdk.java.net  Wed Jun 30 04:45:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 30 Jun 2021 04:45:08 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
Message-ID: <5j7HXm2U9KqM6te-IT7o60Bb3OsLK_temQ4UGi88WWU=.7b8d6548-cf70-49ec-a458-198edf79c35f@github.com>

On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

LGTM

test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java line 64:

> 62: 
> 63:             out.shouldMatch("\".+\" #\\d+ daemon prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");
> 64:             out.shouldMatch("\"main\" #\\d+ prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");

small nit, instead of `[0-9]` you could use `\d`, and to match a hex number `\p{XDigit}` could be used. But since you just follow the existing pattern, I leave it up to you whether you want to change this.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 06:01:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 06:01:00 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <5j7HXm2U9KqM6te-IT7o60Bb3OsLK_temQ4UGi88WWU=.7b8d6548-cf70-49ec-a458-198edf79c35f@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
 <5j7HXm2U9KqM6te-IT7o60Bb3OsLK_temQ4UGi88WWU=.7b8d6548-cf70-49ec-a458-198edf79c35f@github.com>
Message-ID: <wOhiDDmQ27AF_TVE1yQ8g8Vg0vvoxAJJX9RbQ9LjRAw=.f805a13b-79b7-4beb-a01c-07fd22ff3a98@github.com>

On Wed, 30 Jun 2021 04:42:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright
>
> test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java line 64:
> 
>> 62: 
>> 63:             out.shouldMatch("\".+\" #\\d+ daemon prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");
>> 64:             out.shouldMatch("\"main\" #\\d+ prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");
> 
> small nit, instead of `[0-9]` you could use `\d`, and to match a hex number `\p{XDigit}` could be used. But since you just follow the existing pattern, I leave it up to you whether you want to change this.

Good catch! [`\p{XDigit}`](https://www.tutorialspoint.com/javaregex/javaregex_posix_class_xdigit.htm) seems a standard/better way to match any hexadecimal character than `[0-9a-fA-F]+`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 06:30:07 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 06:30:07 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
Message-ID: <0m0q3DCpLM8PFQK11Kur48hGpRPxT5JOa3L2klxlGMg=.c1330a91-4e0d-4fc8-a1ff-1930369fe9ef@github.com>

On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> On 28/06/2021 6:49 pm, Thomas Stuefe wrote:
> 
> > On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang <yyang at openjdk.org> wrote:
> > > > src/hotspot/share/runtime/osThread.cpp line 41:
> > > > > 39: // Printing
> > > > > 40: void OSThread::print_on(outputStream *st) const {
> > > > > 41:   st->print("nid=%d ", thread_id());
> > > > 
> > > > 
> > > > thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.
> > > 
> > > 
> > > Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:
> > 
> > 
> > You'd do:
> > print("nid: " UINT64_FORMAT, (uint64_t) id):;
> > thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.
> 
> If it is opaque then I don't see how signed or unsigned makes any
> difference. You are assuming it can just be treated as a 64-bit value;
> whether you interpret that as a signed or unsigned value just changes
> how you print it. I agree printing only positive values is nicer visually.
> 
> David

@dholmes-ora David, can you plz take a look at latest versions once you have time. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 06:38:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 06:38:30 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v5]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  use \p{XDigit}

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/6d3d0523..7a30c3df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From dnsimon at openjdk.java.net  Wed Jun 30 07:17:00 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 30 Jun 2021 07:17:00 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v3]
In-Reply-To: <r8gGOI8hoZN4Qlf3Mit6w-7gGglXSym54mRnlSi9ozw=.087ffd7c-fdee-4947-94ff-30249d1c9fa2@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
 <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
 <r8gGOI8hoZN4Qlf3Mit6w-7gGglXSym54mRnlSi9ozw=.087ffd7c-fdee-4947-94ff-30249d1c9fa2@github.com>
Message-ID: <E859jgnRHOfHfKMU8pINwUAPLFHMw-8crvS6ZlG87-o=.e9a9681b-9413-45d4-a6a7-21be350624bd@github.com>

On Tue, 29 Jun 2021 22:14:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   respect ErrorFileToStdout and ErrorFileToStderr flags
>
> Okay. this is fine.
> 
> Still you need review from Runtime group. I will ping them.

Thanks for the review David. If it's all the same, I'll keep the ErrorFileToStdOut/Err behavior for this libjvmci error reporting. Looking at the rationale for https://bugs.openjdk.java.net/browse/JDK-8220786, it makes sense for libjvmci error reporting to go to the console when retrieving log files from container environments is problematic. It might even be worth having CI compiler replay respect these flags but that's a separate question that I leave up to @vnkozlov.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4620

From xliu at openjdk.java.net  Wed Jun 30 07:27:06 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 30 Jun 2021 07:27:06 GMT
Subject: RFR: JDK-8269571: NMT should print total malloc bytes and
 invocation count
In-Reply-To: <9Lob0jf8Oldn3uY87mP75Il7WB6yTg9Dzz9lywMTtn0=.acf9e8fd-e3a8-4f4a-8339-4b15e72c6650@github.com>
References: <n5PWdzYtQ7hUvZ4nGzThmHIJbUaPF3fi6YK9i26EEuw=.adf58d38-c6f6-4949-9c23-3950c4371c94@github.com>
 <myy-5JmQi94G-wDP1Cq1U-LLdiSa49-3m9vPnoPWKuk=.d41161b5-45e4-4aab-ba82-780395729f95@github.com>
 <9Lob0jf8Oldn3uY87mP75Il7WB6yTg9Dzz9lywMTtn0=.acf9e8fd-e3a8-4f4a-8339-4b15e72c6650@github.com>
Message-ID: <kQ8sGdM7AgrTOXJrAwQY791Riah7l7h7eA1bSwJRpzw=.75617087-fbb1-44b0-a033-fef5f0e2a07b@github.com>

On Wed, 30 Jun 2021 04:37:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > your change looks good to me.
> 
> Thanks!
> 
> > > ```
> > >    malloc: 40590KB #13669
> > > ```
> > 
> > 
> > I think 13669 is the invocation count of malloc(). Out of curiosity, may I know how to use it? Do you intend to use this to pinpoint memleak from malloc()? A straight malloc() icount may not help much. Is it possible we can have the number of unbalanced malloc()? That is icount of malloc() minus icount of free(). of course, it is not directly related to this PR.
> 
> That count is not the invocation counter (which can be useful too under certain conditions) but the number of outstanding allocations.
I see.  I take a look at mallocTracker.hpp. It's unbalanced count.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4622

From dnsimon at openjdk.java.net  Wed Jun 30 09:57:29 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 30 Jun 2021 09:57:29 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v4]
In-Reply-To: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
Message-ID: <6Cl9W6gwy79SypouhXiUwwwmGKmf0nl3iC9Pg0fu41w=.4552c8c6-3c20-4a3f-abbc-29b2a0532165@github.com>

> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
> 
> For example:
> 
>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
> #  fatal error: thread 41219: Fatal error in JVMCI shared library
> #
> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
> #
> # The JVMCI shared library error data is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  use fdStream instead of fileStream

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4620/files
  - new: https://git.openjdk.java.net/jdk/pull/4620/files/ba004ef0..fac6c3dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=02-03

  Stats: 19 lines in 2 files changed: 2 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4620/head:pull/4620

PR: https://git.openjdk.java.net/jdk/pull/4620

From zgu at openjdk.java.net  Wed Jun 30 11:40:08 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Jun 2021 11:40:08 GMT
Subject: [jdk17] RFR: 8269594: assert(_handle_mark_nesting > 1) failed:
 memory leak: allocating handle outside HandleMark
In-Reply-To: <NYiuSq7o_phBQSp4Vv43nVLiYsQw3ADKaQSLjnj9g9M=.39ee43ba-ee30-49b3-ac04-6c5aca722676@github.com>
References: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
 <NYiuSq7o_phBQSp4Vv43nVLiYsQw3ADKaQSLjnj9g9M=.39ee43ba-ee30-49b3-ac04-6c5aca722676@github.com>
Message-ID: <o3BlXphCApEHqTm4ZdVM8LtYPS06YodxY-MJlvQSHFk=.4551f3c0-a469-4394-8584-c8cf9ef62555@github.com>

On Tue, 29 Jun 2021 18:41:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I would like to fix this assertion in jdk17. It was caught in Shenandoah nightly test and hard to reproduce, but fix is simple and low risk.
>
> This looks good.  I think it's worth fixing because the Handles could leak without this assert in production, and that could be really hard to diagnose.

@coleenp @JornVernee Thanks!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/173

From zgu at openjdk.java.net  Wed Jun 30 11:40:09 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Jun 2021 11:40:09 GMT
Subject: [jdk17] Integrated: 8269594: assert(_handle_mark_nesting > 1) failed:
 memory leak: allocating handle outside HandleMark
In-Reply-To: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
References: <TImLExZ560dUloB8yPee4fY8r2BkiybQaWZOdSXt6rY=.75d7facc-5e34-46e8-875b-66d8ef9af3bc@github.com>
Message-ID: <mspru6L8atikcLH64jQrsgYk6Y-25g2iZlD_Xek5jB4=.019cb903-41e6-496f-a238-6b93360cac61@github.com>

On Tue, 29 Jun 2021 16:02:53 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to fix this assertion in jdk17. It was caught in Shenandoah nightly test and hard to reproduce, but fix is simple and low risk.

This pull request has now been integrated.

Changeset: 4b4bef4e
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/4b4bef4e1e06c8efbfeb2c28e0658ce91ee9ad66
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark

Reviewed-by: coleenp, jvernee

-------------

PR: https://git.openjdk.java.net/jdk17/pull/173

From david.holmes at oracle.com  Wed Jun 30 12:32:42 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Jun 2021 22:32:42 +1000
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v3]
In-Reply-To: <E859jgnRHOfHfKMU8pINwUAPLFHMw-8crvS6ZlG87-o=.e9a9681b-9413-45d4-a6a7-21be350624bd@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
 <x0o1yfw38YWExK9sgJzR1uKp_JObdMK7BZgEtmUS30A=.06026c4d-8d91-487b-9ea4-b2b3c9202ee3@github.com>
 <r8gGOI8hoZN4Qlf3Mit6w-7gGglXSym54mRnlSi9ozw=.087ffd7c-fdee-4947-94ff-30249d1c9fa2@github.com>
 <E859jgnRHOfHfKMU8pINwUAPLFHMw-8crvS6ZlG87-o=.e9a9681b-9413-45d4-a6a7-21be350624bd@github.com>
Message-ID: <10aef568-5558-6860-62eb-beab6edfd237@oracle.com>

On 30/06/2021 5:17 pm, Doug Simon wrote:
> On Tue, 29 Jun 2021 22:14:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> 
>>> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>>>
>>>    respect ErrorFileToStdout and ErrorFileToStderr flags
>>
>> Okay. this is fine.
>>
>> Still you need review from Runtime group. I will ping them.
> 
> Thanks for the review David. If it's all the same, I'll keep the ErrorFileToStdOut/Err behavior for this libjvmci error reporting. Looking at the rationale for https://bugs.openjdk.java.net/browse/JDK-8220786, it makes sense for libjvmci error reporting to go to the console when retrieving log files from container environments is problematic. It might even be worth having CI compiler replay respect these flags but that's a separate question that I leave up to @vnkozlov.

No problem. I hadn't seen that you'd made the change when I made the 
comment.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4620
> 

From dnsimon at openjdk.java.net  Wed Jun 30 12:38:31 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 30 Jun 2021 12:38:31 GMT
Subject: RFR: 8269416: [JVMCI] capture libjvmci crash data to a file [v5]
In-Reply-To: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
Message-ID: <vJYQb3lU4n47RP_APzGbHrUUyVYdWbsBAHsc6r8h6y8=.a37e0ce2-54ce-4f18-b49f-5bda2a9b3fae@github.com>

> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
> 
> For example:
> 
>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
> #  fatal error: thread 41219: Fatal error in JVMCI shared library
> #
> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
> #
> # The JVMCI shared library error data is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  avoid allocating name_buffer when using ErrorFileToStdout/err

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4620/files
  - new: https://git.openjdk.java.net/jdk/pull/4620/files/fac6c3dc..b9f27c7c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4620&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4620/head:pull/4620

PR: https://git.openjdk.java.net/jdk/pull/4620

From dnsimon at openjdk.java.net  Wed Jun 30 12:38:32 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 30 Jun 2021 12:38:32 GMT
Subject: Integrated: 8269416: [JVMCI] capture libjvmci crash data to a file
In-Reply-To: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
References: <0fS5y8qZ0_n3dJHKPW23m_gRKtBZ2eX6NtoyhDoZpfg=.b55e1aa6-e305-4dfb-bc33-e799394b8a0e@github.com>
Message-ID: <I5BaBi1O9WcLT3ttQbnC_tInCF5U8akJHXm3mUmW8bI=.b389d6a5-ffc9-4d18-98e7-591450675e7f@github.com>

On Mon, 28 Jun 2021 22:58:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> When a fatal error occurs in libgraal, it writes a crash dump to `tty`. Instead, it should be captured in a separate log file that is then referenced in the HotSpot crash summary (just like the hs_err_pid and CI replay compile log files are). This allows libgraal crash data to be more easily submitted along with VM crash reports.
> 
> For example:
> 
>> java -Dlibgraal.CrashAtIsFatal=true -Dgraal.CrashAt=String.equals -cp bin CountUppercase skjdf
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (jvmciRuntime.cpp:909), pid=36298, tid=41219
> #  fatal error: thread 41219: Fatal error in JVMCI shared library
> #
> # JRE version: OpenJDK Runtime Environment GraalVM LIBGRAAL 21.3.0-dev (16.0.2) (build 16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16)
> # Java VM: OpenJDK 64-Bit Server VM GraalVM LIBGRAAL 21.3.0-dev (16.0.2-internal+0-adhoc.dnsimon.labsjdk-ce-16, mixed mode, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298.log
> #
> # The JVMCI shared library error data is saved as:
> # /Users/dnsimon/graal/graal/compiler/hs_err_pid36298_libjvmci.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

This pull request has now been integrated.

Changeset: a6b253d8
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6b253d85c732ddd1d3154d5fc108d2bba66ab01
Stats:     96 lines in 7 files changed: 93 ins; 0 del; 3 mod

8269416: [JVMCI] capture libjvmci crash data to a file

Reviewed-by: kvn, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4620

From pchilanomate at openjdk.java.net  Wed Jun 30 15:57:01 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 30 Jun 2021 15:57:01 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <fGk8kHg2GTT2NnXUy6GMD87cET1gIWm3yXZyYXNicoM=.55d3a904-086a-43fb-901d-32b58679b55d@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Hi David,

Changes look good to me.

Thanks,
Patricio

-------------

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 16:46:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 16:46:05 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Looks good to me. I had a hard time with all the whitespace indentation
changes. Previously I would look at the webrev to filter out that whitespace
difference, but I guess webrev via GitHub doesn't do that anymore.

I'm going to download the patch and do one more sanity check
locally so I can convince myself that nothing unexpected changed.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 17:08:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:08:10 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <Uo9S3GGZUFzI6oA3Ku8RClqgFrPqS4sqGpJepe1DV8M=.d3cefea1-6e27-428f-9bdc-9bc39e2c445e@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Finished my re-review without the whitespace noise. I have to say
that really reveals how nice this cleanup is! Thanks for doing it.

I only added some nits. Feel free to fix or not.

src/hotspot/share/compiler/compileBroker.cpp line 938:

> 936:     if (UseDynamicNumberOfCompilerThreads && type == compiler_t
> 937:         && comp->num_compiler_threads() > 0) {
> 938:       // the new thread is not known to Thread-SMR yet so we can just delete

nit: s/the/The/  and add a period to the end of the sentence.

src/hotspot/share/prims/jvmtiEnv.cpp line 1335:

> 1333:   // JavaThread due to lack of memory.
> 1334:   if (new_thread == NULL || new_thread->osthread() == NULL) {
> 1335:     // the new thread is not known to Thread-SMR yet so we can just delete

nit: s/the/The/ and add a period to the end of the sentence.

src/hotspot/share/runtime/monitorDeflationThread.cpp line 51:

> 49:                           CHECK);
> 50: 
> 51:   MonitorDeflationThread* thread =  new MonitorDeflationThread(&monitor_deflation_thread_entry);

nit: s/=  new/= new/

(Not your typo, but please fix it while you're in here.)

src/hotspot/share/runtime/notificationThread.cpp line 63:

> 61:                           THREAD);
> 62: 
> 63:    NotificationThread* thread =  new NotificationThread(&notification_thread_entry);

nit: s/= new/= new/

(Not your typo, but please fix it while you're in here.)

src/hotspot/share/runtime/thread.cpp line 3911:

> 3909:   MutexLocker mu(current, Threads_lock);
> 3910: 
> 3911:   // Initialize the fields of the thread_oop first

nit: please add a period to the end of the sentence.

src/hotspot/share/runtime/thread.cpp line 3923:

> 3921:   java_lang_Thread::set_daemon(thread_oop());
> 3922: 
> 3923:   // Now bind the thread_oop to the target JavaThread

nit: please add a period to the end of the sentence.

src/hotspot/share/services/attachListener.cpp line 490:

> 488:   JavaThread::vm_exit_on_thread_allocation_failure(thread);
> 489: 
> 490:   JavaThread::start_internal_daemon(THREAD, thread, thread_oop, NoPriority);

I wonder if the lack of a specific priority for the attach listener is a
contributing factor to some of the timeouts in attach that we observe.
@plummercj and @sspitsyn - You might be interested here...

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 17:33:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:33:17 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
Message-ID: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>

A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

-------------

Commit messages:
 - 8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64

Changes: https://git.openjdk.java.net/jdk17/pull/182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269691
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/182/head:pull/182

PR: https://git.openjdk.java.net/jdk17/pull/182

From kvn at openjdk.java.net  Wed Jun 30 17:43:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 30 Jun 2021 17:43:04 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
Message-ID: <a42G073iSTXEAMCFE8apTuxq9IGiX-ArfMwX4mTlDqo=.18e971ef-811c-4b15-b04b-3bff6fb8ac6f@github.com>

On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

trivial

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/182

From darcy at openjdk.java.net  Wed Jun 30 17:43:04 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 30 Jun 2021 17:43:04 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
Message-ID: <Jq6CRUyQ6GRt-yCc8Ku3Tg2nMRWQm3Sn36QeKTGz6g0=.97a29682-a93a-45ba-a3e7-d6f1e7ca4d96@github.com>

On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/182

From dcubed at openjdk.java.net  Wed Jun 30 17:43:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:43:05 GMT
Subject: [jdk17] Integrated: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
Message-ID: <uD6oYCCY-YW3mB23rYv2_PLpZqgSBFWRYZ4Hj1fSWFQ=.115f24c5-cb57-4b27-934b-ad08498c41a1@github.com>

On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

This pull request has now been integrated.

Changeset: 2b17e95e
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/2b17e95e202a3feae7bf7ccb6af93881ad6de0c3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64

Reviewed-by: kvn, darcy

-------------

PR: https://git.openjdk.java.net/jdk17/pull/182

From dcubed at openjdk.java.net  Wed Jun 30 17:43:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:43:04 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <a42G073iSTXEAMCFE8apTuxq9IGiX-ArfMwX4mTlDqo=.18e971ef-811c-4b15-b04b-3bff6fb8ac6f@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
 <a42G073iSTXEAMCFE8apTuxq9IGiX-ArfMwX4mTlDqo=.18e971ef-811c-4b15-b04b-3bff6fb8ac6f@github.com>
Message-ID: <T3eVSW0AcmusfS6ouiM2U9lNL5WQKXGRmzNY1rbE-N8=.d7769546-7894-42c3-90d8-2bc30d0d1354@github.com>

On Wed, 30 Jun 2021 17:35:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.
>
> trivial

@vnkozlov and @jddarcy - Thanks for the fast reviews!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/182

From zgu at openjdk.java.net  Wed Jun 30 17:58:13 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Jun 2021 17:58:13 GMT
Subject: RFR: 8269678: Remove unimplemented and unused os::bind_to_processor()
Message-ID: <L5lun4sc1n4vG7sNk93K4ukzVqiXWtXw6CBYPstI-Bg=.6eb81bbd-de63-4193-a384-aaca0625dd44@github.com>

Please review this trivial patch that removes unimplemented and unused method, appears to be a leftover from Solaris port.

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.java.net/jdk/pull/4640/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4640&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269678
  Stats: 24 lines in 5 files changed: 0 ins; 24 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4640.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4640/head:pull/4640

PR: https://git.openjdk.java.net/jdk/pull/4640

From dnsimon at openjdk.java.net  Wed Jun 30 18:38:08 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 30 Jun 2021 18:38:08 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>
Message-ID: <0PS3k4WFWkbG30DSNhuCnpk4oeguVW8BQKANsGsO4Gg=.da20cbce-9fa6-4de8-92bb-bf4279d64fd3@github.com>

On Wed, 30 Jun 2021 16:43:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Looks good to me. I had a hard time with all the whitespace indentation

https://github.blog/2018-05-01-ignore-white-space-in-code-review/

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From coleenp at openjdk.java.net  Wed Jun 30 18:56:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 30 Jun 2021 18:56:06 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Some small change requests.

src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp line 49:

> 47:   assert(proc != NULL, "invariant");
> 48: 
> 49:   JavaThread* new_thread = new JavaThread(proc);

if new_thread allocation fails, the operator new will call vm_exit_out_of_memory and exit. It won't return NULL.

src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp line 54:

> 52:   // osthread was created for the JavaThread due to lack of memory.
> 53:   if (new_thread == NULL || new_thread->osthread() == NULL) {
> 54:     delete new_thread;

Since new_thread can't be null, this delete is going to be ok, but it would better not to check for null.

src/hotspot/share/prims/jvmtiEnv.cpp line 1334:

> 1332:   // At this point it may be possible that no osthread was created for the
> 1333:   // JavaThread due to lack of memory.
> 1334:   if (new_thread == NULL || new_thread->osthread() == NULL) {

Same here, unless there's some operator new overloading that doesn't use the nothrow operator new.

src/hotspot/share/runtime/notificationThread.cpp line 61:

> 59:                           vmSymbols::thread_void_signature(),
> 60:                           thread_oop,
> 61:                           THREAD);

This was all the code that I thought was unnecessarily duplicated.

src/hotspot/share/runtime/thread.cpp line 3935:

> 3933:   // in that case. However, since this must work and we do not allow
> 3934:   // exceptions anyway, check and abort if this fails.
> 3935:   if (thread == nullptr || thread->osthread() == nullptr) {

thread shouldn't be NULL here if you haven't used a nothrow version of new to allocate the thread.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From coleenp at openjdk.java.net  Wed Jun 30 18:56:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 30 Jun 2021 18:56:07 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
Message-ID: <K8MDn-C4DC39Od5dXdNnq7w1M6FCSFY2OyomoUD6CpE=.9706b47b-bf21-4c0e-864e-46cfbe3d1818@github.com>

On Wed, 30 Jun 2021 18:44:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed copyright years in hpp files
>
> src/hotspot/share/runtime/thread.cpp line 3935:
> 
>> 3933:   // in that case. However, since this must work and we do not allow
>> 3934:   // exceptions anyway, check and abort if this fails.
>> 3935:   if (thread == nullptr || thread->osthread() == nullptr) {
> 
> thread shouldn't be NULL here if you haven't used a nothrow version of new to allocate the thread.

Since you're no longer holding the JavaThreads_lock here, it seems like you could do this from the JavaThread constructor instead of adding this function. Except for the case for the JFR thread and JVMTI. So maybe you need this.  Maybe fix the comment at the end of JavaThread constructor that says you're holding a lock and are going to throw OOM and those details.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 19:02:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 19:02:04 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <0PS3k4WFWkbG30DSNhuCnpk4oeguVW8BQKANsGsO4Gg=.da20cbce-9fa6-4de8-92bb-bf4279d64fd3@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>
 <0PS3k4WFWkbG30DSNhuCnpk4oeguVW8BQKANsGsO4Gg=.da20cbce-9fa6-4de8-92bb-bf4279d64fd3@github.com>
Message-ID: <zESOcaQLSHnN9zuEQ7uURPYQrCMNCvfffnGJb61tKV0=.1aa133d0-2faf-4bf9-a73f-7e0ed4222b7a@github.com>

On Wed, 30 Jun 2021 18:34:50 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> https://github.blog/2018-05-01-ignore-white-space-in-code-review/

My "Files Changed" view doesn't have a "diff settings" button, but I did click
on the Settings widget and found a button where I could ignore "white space".
Pretty cool. Thanks for the tip @dougxc

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 19:11:09 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 19:11:09 GMT
Subject: RFR: 8269678: Remove unimplemented and unused
 os::bind_to_processor()
In-Reply-To: <L5lun4sc1n4vG7sNk93K4ukzVqiXWtXw6CBYPstI-Bg=.6eb81bbd-de63-4193-a384-aaca0625dd44@github.com>
References: <L5lun4sc1n4vG7sNk93K4ukzVqiXWtXw6CBYPstI-Bg=.6eb81bbd-de63-4193-a384-aaca0625dd44@github.com>
Message-ID: <myKvu0hvVtf503nuIJIuF6SMKXY7aPcWBz3FqkZxCRw=.30869bf9-fd4d-4c95-a3ad-c5fea60c8787@github.com>

On Wed, 30 Jun 2021 13:54:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch that removes unimplemented and unused method, appears to be a leftover from Solaris port.

Thumbs up. This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4640

From zgu at openjdk.java.net  Wed Jun 30 19:56:08 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Jun 2021 19:56:08 GMT
Subject: RFR: 8269678: Remove unimplemented and unused
 os::bind_to_processor()
In-Reply-To: <myKvu0hvVtf503nuIJIuF6SMKXY7aPcWBz3FqkZxCRw=.30869bf9-fd4d-4c95-a3ad-c5fea60c8787@github.com>
References: <L5lun4sc1n4vG7sNk93K4ukzVqiXWtXw6CBYPstI-Bg=.6eb81bbd-de63-4193-a384-aaca0625dd44@github.com>
 <myKvu0hvVtf503nuIJIuF6SMKXY7aPcWBz3FqkZxCRw=.30869bf9-fd4d-4c95-a3ad-c5fea60c8787@github.com>
Message-ID: <LtwLzA7Nru52ZitGFZaBjuuGXB5FJXx_TgylRSeIidQ=.14d19032-0c6b-4624-9367-829ed64162ca@github.com>

On Wed, 30 Jun 2021 19:07:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Please review this trivial patch that removes unimplemented and unused method, appears to be a leftover from Solaris port.
>
> Thumbs up. This is a trivial fix.

@dcubed-ojdk  Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4640

From zgu at openjdk.java.net  Wed Jun 30 19:56:08 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Jun 2021 19:56:08 GMT
Subject: Integrated: 8269678: Remove unimplemented and unused
 os::bind_to_processor()
In-Reply-To: <L5lun4sc1n4vG7sNk93K4ukzVqiXWtXw6CBYPstI-Bg=.6eb81bbd-de63-4193-a384-aaca0625dd44@github.com>
References: <L5lun4sc1n4vG7sNk93K4ukzVqiXWtXw6CBYPstI-Bg=.6eb81bbd-de63-4193-a384-aaca0625dd44@github.com>
Message-ID: <iG5B6ykvaYRoPNs3cj7ZDC1atqbOEGiBWx2izNQzp0w=.597d9cd2-ecd1-4726-8857-ade55493c1cc@github.com>

On Wed, 30 Jun 2021 13:54:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch that removes unimplemented and unused method, appears to be a leftover from Solaris port.

This pull request has now been integrated.

Changeset: 5c08344b
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5c08344b646b92f3357a0daf32e77b21da5859ec
Stats:     24 lines in 5 files changed: 0 ins; 24 del; 0 mod

8269678: Remove unimplemented and unused os::bind_to_processor()

Reviewed-by: dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/4640

From dcubed at openjdk.java.net  Wed Jun 30 21:28:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 21:28:17 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
Message-ID: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>

A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
on Windows-X64 with -Xcomp.

-------------

Commit messages:
 - 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp

Changes: https://git.openjdk.java.net/jdk17/pull/186/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=186&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269703
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/186/head:pull/186

PR: https://git.openjdk.java.net/jdk17/pull/186

From dholmes at openjdk.java.net  Wed Jun 30 22:17:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 22:17:01 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
Message-ID: <mTHVmR6LFhhxZ8mfbPma06_HMpTnkzAqMsqsGH44IOs=.1751660f-f953-4567-b2b6-5bfdb1c850a8@github.com>

On Wed, 30 Jun 2021 21:21:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
> on Windows-X64 with -Xcomp.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From dcubed at openjdk.java.net  Wed Jun 30 22:17:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 22:17:01 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <mTHVmR6LFhhxZ8mfbPma06_HMpTnkzAqMsqsGH44IOs=.1751660f-f953-4567-b2b6-5bfdb1c850a8@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
 <mTHVmR6LFhhxZ8mfbPma06_HMpTnkzAqMsqsGH44IOs=.1751660f-f953-4567-b2b6-5bfdb1c850a8@github.com>
Message-ID: <UzkarwIgPuVDmoYcXO-3Ut9TkNG3Bsq_gLsJsc8b5v8=.3ab2ac45-ffe8-4ed0-bb9c-79cf908cf22d@github.com>

On Wed, 30 Jun 2021 22:11:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
>> on Windows-X64 with -Xcomp.
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From dcubed at openjdk.java.net  Wed Jun 30 22:17:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 22:17:02 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
Message-ID: <lNFkeLgD4cJ7iyRrA9VCWN6Ok7Psbb9Za2BCOpptySM=.68fa907f-0f73-400d-a770-7ee10a7432f3@github.com>

On Wed, 30 Jun 2021 21:21:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
> on Windows-X64 with -Xcomp.

Cool. I typo'ed the "/integrate" and then edited it. The command still worked.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From dcubed at openjdk.java.net  Wed Jun 30 22:17:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 22:17:02 GMT
Subject: [jdk17] Integrated: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
Message-ID: <08weo1J3kupDlwxUeXA0Z5PJfE5Cagj0aSqhm-D-oSE=.f0bf126a-8785-4e6b-a37d-a73d67e923d8@github.com>

On Wed, 30 Jun 2021 21:21:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
> on Windows-X64 with -Xcomp.

This pull request has now been integrated.

Changeset: aba6c55d
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/aba6c55dacf020d547771c5141092e4b931c232e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From nekocaffeine at qq.com  Tue Jun 29 07:53:24 2021
From: nekocaffeine at qq.com (=?ISO-8859-1?B?TmVrb0NhZmZlaW5l?=)
Date: Tue, 29 Jun 2021 07:53:24 -0000
Subject: Confusion about stack map verify of constructors
Message-ID: <tencent_F01B703903B832142BF08C91493C074CE606@qq.com>

Hi everyone,


When a super constructor is called in a TryCatchBlock,
&nbsp;none of the following exception handler locals will pass validation,
&nbsp;uninitializedThis, referenceName, TOP, <empty&gt;, java/lang/Object.


Where uninitializedThis and referenceName are mutually exclusive,
&nbsp;and either one will fail because it does not contain the other.
TOP will fail because it is not compatible with the flags of uninitializedThis.
<empty&gt; will fail for incompatibility with uninitializedThis.


Is there a stackframe that passes validation?


Thanks in advance,
NekoCaffeine