From sviswanathan at openjdk.java.net  Sat May  1 00:02:02 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 1 May 2021 00:02:02 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v3]
In-Reply-To: <Gk50ppXVcAR_XeRBtLm7Mkmz0EHjnM9yyp0L6VQEhWw=.691f12c3-9a42-49bc-bc26-452522dd464f@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <Gk50ppXVcAR_XeRBtLm7Mkmz0EHjnM9yyp0L6VQEhWw=.691f12c3-9a42-49bc-bc26-452522dd464f@github.com>
Message-ID: <ecNM5CkCMxzQuifGlAmjHCwvwmAKNMOdyhJ_rNXng9E=.6fcfeb8a-ee9a-4a0a-97d8-502133bba595@github.com>

On Fri, 30 Apr 2021 21:15:20 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set flag UseAdler32Intrinsics differently to based on 64 or 32-bit modes.

src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 2:

> 1: /*
> 2: * Copyright (c) 2016, Intel Corporation.

Copyright year should be 2021.

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

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

From kbarrett at openjdk.java.net  Sat May  1 09:48:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 1 May 2021 09:48:53 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <xGjqiPgJSwWEzXIZFFjqHBVvo8q24f18Jqtlsag0jNg=.c2d94f1d-1399-443d-ab62-80080499db6d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <xGjqiPgJSwWEzXIZFFjqHBVvo8q24f18Jqtlsag0jNg=.c2d94f1d-1399-443d-ab62-80080499db6d@github.com>
Message-ID: <Krss8iIpbEmSyktS3a2G1hWH0Vi7CYBQW2tdtjwepXQ=.2fd26a37-c31a-479e-b858-36c0114e9276@github.com>

On Sun, 25 Apr 2021 17:32:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> src/hotspot/share/classfile/stringTable.cpp line 355:
> 
>> 353:   // Notify deduplication support that the string is being interned.  A string
>> 354:   // must never be deduplicated after it has been interned.  Doing so interferes
>> 355:   // with compiler optimizations don on e.g. interned string literals.
> 
> typo: don -> done

Fixed locally.

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

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

From kbarrett at openjdk.java.net  Sat May  1 09:48:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 1 May 2021 09:48:52 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com>
Message-ID: <ABYqskG_59_tAs4or_JV1J1oEPab3DCPGz9hnSgJkoc=.b097a569-c511-4072-8d60-8fb301a1cde3@github.com>

On Tue, 27 Apr 2021 22:30:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> src/hotspot/share/classfile/javaClasses.inline.hpp line 77:
> 
>> 75: 
>> 76: uint8_t* java_lang_String::flags_addr(oop java_string) {
>> 77:   assert(_initialized, "Mut be initialized");
> 
> typo: must

Fixed locally.

> src/hotspot/share/runtime/globals.hpp line 1994:
> 
>> 1992:                                                                             \
>> 1993:   product(uint64_t, StringDeduplicationHashSeed, 0, DIAGNOSTIC,             \
>> 1994:           "Seed for the table hashing function; 0 requests computed seed")  \
> 
> Should these two really be develop() options?

StringDeduplicationResizeALot is used by a test that we want to run against release builds too.  If StringDeduplicationHashSeed isn't a diagnostic option (so available in release builds), I'd be more inclined to just remove it than to make it a develop option.

> src/hotspot/share/runtime/mutexLocker.cpp line 239:
> 
>> 237:     def(StringDedupQueue_lock      , PaddedMonitor, leaf,        true,  _safepoint_check_never);
>> 238:     def(StringDedupTable_lock      , PaddedMutex  , leaf + 1,    true,  _safepoint_check_never);
>> 239:   }
> 
> Why weren't these duplicate definitions?  This is disturbing.

These are assignments, not definitions.  Only one of the assignments was being performed because only one of G1 or Shenandoah will be selected.  (Not that it matters anymore after this change.)

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

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

From kbarrett at openjdk.java.net  Sat May  1 09:48:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 1 May 2021 09:48:53 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <FJbJvc9ISiPyR9soIaPwTTK2Fd4D_jJfA17u0GGujH0=.1d310efe-73fb-495a-bfe4-726d25922599@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com>
 <FJbJvc9ISiPyR9soIaPwTTK2Fd4D_jJfA17u0GGujH0=.1d310efe-73fb-495a-bfe4-726d25922599@github.com>
Message-ID: <4phWY5RsYDtwmG0Ap_8qV4SID8wKxYi3lUFSBg8NLHg=.da925bdc-2808-436c-a471-ba35519bb590@github.com>

On Wed, 28 Apr 2021 00:29:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/stringTable.cpp line 784:
>> 
>>> 782:   SharedStringIterator iter(f);
>>> 783:   _shared_table.iterate(&iter);
>>> 784: }
>> 
>> So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie
>> 
>> // The CDS archive does not include the string deduplication table. Only the string
>> // table is saved in the archive. The shared strings from CDS archive need to be
>> // added to the string deduplication table before deduplication occurs. That is
>> // done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()).
>> void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) {
>>   StringDedupSharedClosure sharedStringDedup(stat);
>>   StringTable::shared_oops_do(&sharedStringDedup);
>> }
>> Asking @iklam to have a look then.
>
> If I understand correctly, we no longer need to add the entire set of shared strings into the dedup table.
> 
> 
> +// As a space optimization, when shared StringTable entries exist the shared
> +// part of the StringTable is also used as a source for byte arrays.  This
> +// permits deduplication of strings against those shared entries without
> +// recording them in this table too.
> +class StringDedup::Table : AllStatic {
> 
> ...
> 
> +void StringDedup::Table::deduplicate(oop java_string) {
> +  assert(java_lang_String::is_instance(java_string), "precondition");
> +  _cur_stat.inc_inspected();
> +  if ((StringTable::shared_entry_count() > 0) &&
> +      try_deduplicate_shared(java_string)) {
> +    return;                     // Done if deduplicated against shared StringTable.

Ioi is correct; we deduplicate "directly" against the shared string table rather than adding the shared strings to the deduplication table.

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

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

From kbarrett at openjdk.java.net  Sat May  1 09:48:54 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 1 May 2021 09:48:54 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <FGI2qX4tf43QMa_gHls2WugfANSq1VxMg131ENNGxgE=.26c213e2-dd1c-4155-9622-75035f43981c@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com>
 <FGI2qX4tf43QMa_gHls2WugfANSq1VxMg131ENNGxgE=.26c213e2-dd1c-4155-9622-75035f43981c@github.com>
Message-ID: <Q59Ci83SQ89VeN1_qHouuQ8sItmQ6sQ72odRXFYDUqo=.0610d340-fd1b-446f-9a87-4d7335a528e4@github.com>

On Wed, 28 Apr 2021 06:44:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 557:
>> 
>>> 555:     // non-latin1, and deduplicating if we find a match.  For deduplication we
>>> 556:     // only care if the arrays consist of the same sequence of bytes.
>>> 557:     const jchar* chars = static_cast<jchar*>(value->base(T_CHAR));
>> 
>> The encoding of the shared strings always match CompactStrings. Otherwise the CDS archive will fail to map. E.g.,
>> 
>> 
>> $ java -XX:-CompactStrings -Xshare:dump 
>> $ java -XX:+CompactStrings -Xlog:cds -version
>> ...
>> [0.032s][info][cds] UseSharedSpaces: The shared archive file's CompactStrings 
>>                     setting (disabled) does not equal the current CompactStrings setting (enabled).
>> [0.032s][info][cds] UseSharedSpaces: Unable to map shared spaces
>> ...
>> 
>> 
>> So you can avoid this `if` block when `CompactStrings == true`. The `!java_lang_String::is_latin1(found)` check below can be changed to an assert.
>> 
>> Also, I think we need an explicit test case where you'd return `true` at line 564. I can write a new test case and email to you. I think it will involve dumping an archive with `-XX:-CompactStrings`.
>
> Oh, I realized that my suggestion above is wrong. When `CompactStrings==true`, you can still have a string whose coder is UTF16:
> 
> https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.base/share/classes/java/lang/String.java#L343-L351

Correct.

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

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

From iignatyev at openjdk.java.net  Sat May  1 15:39:50 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 1 May 2021 15:39:50 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
 <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
 <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>
Message-ID: <Dg6AXFfNxSwYmqVI8aImJW3L6pybePpH318ExXMV8WU=.06b513c9-b338-415a-a20e-b5bbf24fd04a@github.com>

On Fri, 30 Apr 2021 22:10:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I'm fine with both approaches. 
>> 
>> Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it.
>
> Let hear @iignatev opinion.

from my point of view, `@requires` is clearer and also eliminates "wasted" execution (if someone tries to run this test w/ `-XX:-UseVtableBasedCHA`), so I'd prefer if we use it.

I have a more generic comment about `UseVtableBasedCHA`. I understand the desire to introduce a flag to switch back to the old implementation, but I'm somewhat concern that it adds a new dimension into configuration space that won't be covered by our existing tests (w/ the test which exercises interesting parts of the related code is inapplicable) and isn't part of our regular test configurations. Can we make it an experimental flag (w/ vtable-based CHA still being enabled by default)? this way, the quality bar for the old implementation will be somewhat lower, yet the end-users will still be able to return to the old implementation if it, for some reason, works better in their use-cases.

-- Igor

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

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

From david.holmes at oracle.com  Sat May  1 22:03:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 2 May 2021 08:03:03 +1000
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <Dg6AXFfNxSwYmqVI8aImJW3L6pybePpH318ExXMV8WU=.06b513c9-b338-415a-a20e-b5bbf24fd04a@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
 <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
 <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>
 <Dg6AXFfNxSwYmqVI8aImJW3L6pybePpH318ExXMV8WU=.06b513c9-b338-415a-a20e-b5bbf24fd04a@github.com>
Message-ID: <f11750cc-be1f-580c-cbcb-38c7d06fa736@oracle.com>

On 2/05/2021 1:39 am, Igor Ignatyev wrote:
> On Fri, 30 Apr 2021 22:10:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> 
>>> I'm fine with both approaches.
>>>
>>> Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it.
>>
>> Let hear @iignatev opinion.
> 
> from my point of view, `@requires` is clearer and also eliminates "wasted" execution (if someone tries to run this test w/ `-XX:-UseVtableBasedCHA`), so I'd prefer if we use it.
> 
> I have a more generic comment about `UseVtableBasedCHA`. I understand the desire to introduce a flag to switch back to the old implementation, but I'm somewhat concern that it adds a new dimension into configuration space that won't be covered by our existing tests (w/ the test which exercises interesting parts of the related code is inapplicable) and isn't part of our regular test configurations. Can we make it an experimental flag (w/ vtable-based CHA still being enabled by default)? this way, the quality bar for the old implementation will be somewhat lower, yet the end-users will still be able to return to the old implementation if it, for some reason, works better in their use-cases.

Did you mean "experimental" in a generic sense or actually change it 
from DIAGNOSTIC to EXPERIMENTAL? If the latter then I don't agree this 
is an experimental flag, it is diagnostic. But either way the testing 
requirements are the same if we expect to tell end users to try this 
flag if they hit an problem - the flag has to be known to be functional, 
so we will have to expand the test coverage.

Cheers,
David
-----

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

From igor.ignatyev at oracle.com  Sun May  2 04:00:50 2021
From: igor.ignatyev at oracle.com (Igor Ignatev)
Date: Sun, 2 May 2021 04:00:50 +0000
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <f11750cc-be1f-580c-cbcb-38c7d06fa736@oracle.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
 <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
 <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>
 <Dg6AXFfNxSwYmqVI8aImJW3L6pybePpH318ExXMV8WU=.06b513c9-b338-415a-a20e-b5bbf24fd04a@github.com>
 <f11750cc-be1f-580c-cbcb-38c7d06fa736@oracle.com>
Message-ID: <B31DD694-3576-47CC-953E-DDB94BB91CA3@oracle.com>

Hi David,

I meant both: in a generic sense, meaning we won't properly document, advertise it or claim it as supported; and changing its type to EXPERIMENTAL, so it will be somewhat harder for people to switch it.

-- Igor

On May 1, 2021, at 3:03 PM, David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>> wrote:

On 2/05/2021 1:39 am, Igor Ignatyev wrote:
On Fri, 30 Apr 2021 22:10:02 GMT, Vladimir Kozlov <kvn at openjdk.org<mailto:kvn at openjdk.org>> wrote:
I'm fine with both approaches.

Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it.

Let hear @iignatev opinion.
from my point of view, `@requires` is clearer and also eliminates "wasted" execution (if someone tries to run this test w/ `-XX:-UseVtableBasedCHA`), so I'd prefer if we use it.
I have a more generic comment about `UseVtableBasedCHA`. I understand the desire to introduce a flag to switch back to the old implementation, but I'm somewhat concern that it adds a new dimension into configuration space that won't be covered by our existing tests (w/ the test which exercises interesting parts of the related code is inapplicable) and isn't part of our regular test configurations. Can we make it an experimental flag (w/ vtable-based CHA still being enabled by default)? this way, the quality bar for the old implementation will be somewhat lower, yet the end-users will still be able to return to the old implementation if it, for some reason, works better in their use-cases.

Did you mean "experimental" in a generic sense or actually change it from DIAGNOSTIC to EXPERIMENTAL? If the latter then I don't agree this is an experimental flag, it is diagnostic. But either way the testing requirements are the same if we expect to tell end users to try this flag if they hit an problem - the flag has to be known to be functional, so we will have to expand the test coverage.

Cheers,
David
-----

-- Igor
-------------
PR: https://git.openjdk.java.net/jdk/pull/3727


From david.holmes at oracle.com  Sun May  2 05:54:47 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 2 May 2021 15:54:47 +1000
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <B31DD694-3576-47CC-953E-DDB94BB91CA3@oracle.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
 <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
 <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>
 <Dg6AXFfNxSwYmqVI8aImJW3L6pybePpH318ExXMV8WU=.06b513c9-b338-415a-a20e-b5bbf24fd04a@github.com>
 <f11750cc-be1f-580c-cbcb-38c7d06fa736@oracle.com>
 <B31DD694-3576-47CC-953E-DDB94BB91CA3@oracle.com>
Message-ID: <c11b803e-d538-f891-1386-026dcc71e285@oracle.com>

On 2/05/2021 2:00 pm, Igor Ignatev wrote:
> Hi David,
> 
> I meant both: in a generic sense, meaning we won't properly document, 
> advertise it or claim it as supported; and changing its type to 
> EXPERIMENTAL, so it will be somewhat harder for people to switch it.

Both forms are as hard to switch to as both must be unlocked. But 
semantically this is not an experimental flag IMO.

Regardless, if the intent is to allow the flag to be used to restore 
legacy behaviour, then that legacy behaviour must be tested. We don't 
have to run thousands of tests with the flag disabled, just something 
representative enough to give us confidence that the code has not 
bit-rotted.

Cheers,
David

> -- Igor
> 
>> On May 1, 2021, at 3:03 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> On 2/05/2021 1:39 am, Igor Ignatyev wrote:
>>> On Fri, 30 Apr 2021 22:10:02 GMT, Vladimir Kozlov <kvn at openjdk.org 
>>> <mailto:kvn at openjdk.org>> wrote:
>>>>> I'm fine with both approaches.
>>>>>
>>>>> Explicitly setting the flag looked to me more robust and clearer 
>>>>> communicating the intent. But if you prefer `@requires`, I'll use it.
>>>>
>>>> Let hear @iignatev opinion.
>>> from my point of view, `@requires` is clearer and also eliminates 
>>> "wasted" execution (if someone tries to run this test w/ 
>>> `-XX:-UseVtableBasedCHA`), so I'd prefer if we use it.
>>> I have a more generic comment about `UseVtableBasedCHA`. I understand 
>>> the desire to introduce a flag to switch back to the old 
>>> implementation, but I'm somewhat concern that it adds a new dimension 
>>> into configuration space that won't be covered by our existing tests 
>>> (w/ the test which exercises interesting parts of the related code is 
>>> inapplicable) and isn't part of our regular test configurations. Can 
>>> we make it an experimental flag (w/ vtable-based CHA still being 
>>> enabled by default)? this way, the quality bar for the old 
>>> implementation will be somewhat lower, yet the end-users will still 
>>> be able to return to the old implementation if it, for some reason, 
>>> works better in their use-cases.
>>
>> Did you mean "experimental" in a generic sense or actually change it 
>> from DIAGNOSTIC to EXPERIMENTAL? If the latter then I don't agree this 
>> is an experimental flag, it is diagnostic. But either way the testing 
>> requirements are the same if we expect to tell end users to try this 
>> flag if they hit an problem - the flag has to be known to be 
>> functional, so we will have to expand the test coverage.
>>
>> Cheers,
>> David
>> -----
>>
>>> -- Igor
>>> -------------
>>> PR:https://git.openjdk.java.net/jdk/pull/3727 
>>> <https://git.openjdk.java.net/jdk/pull/3727>
> 

From chagedorn at openjdk.java.net  Sun May  2 14:42:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Sun, 2 May 2021 14:42:56 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
Message-ID: <P2gEb7CfJxQ2_r__JrTrgXwYbufQp5wubTvIquL3RHk=.7c6e49b9-e0f4-4575-ab74-65c80ab68e08@github.com>

On Fri, 30 Apr 2021 18:33:53 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls
>>  - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings
>
> test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkPrepareFlags.java line 92:
> 
>> 90:                           + String.join(TestFramework.TEST_VM_FLAGS_DELIMITER, flags)
>> 91:                           + System.lineSeparator() + TestFramework.TEST_VM_FLAGS_END;
>> 92:         TestFrameworkSocket.write(encoding, "flag encoding");
> 
> I don't see a need to use socket here, it will significantly simplify the code, the failure analysis, and reproducing if we just save prepared flags into a file w/ a well-known location (e.g. passed as an argument/property to `TestFrameworkPrepareFlags`), and when used command-line argument file (`@-file`) to pass these flags to the test VM.

Okay, yes it would make it easier. But the socket can be kept for the communication between the test VM and the driver VM?

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

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

From iignatyev at openjdk.java.net  Sun May  2 15:55:01 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sun, 2 May 2021 15:55:01 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <P2gEb7CfJxQ2_r__JrTrgXwYbufQp5wubTvIquL3RHk=.7c6e49b9-e0f4-4575-ab74-65c80ab68e08@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
 <P2gEb7CfJxQ2_r__JrTrgXwYbufQp5wubTvIquL3RHk=.7c6e49b9-e0f4-4575-ab74-65c80ab68e08@github.com>
Message-ID: <nEnfA07eeT8NU0-Wo1lBP-SU3k31AHEfDWXD1fRGz5I=.96eb98e5-ea77-43bb-a695-8dcc993b9101@github.com>

On Sun, 2 May 2021 14:39:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkPrepareFlags.java line 92:
>> 
>>> 90:                           + String.join(TestFramework.TEST_VM_FLAGS_DELIMITER, flags)
>>> 91:                           + System.lineSeparator() + TestFramework.TEST_VM_FLAGS_END;
>>> 92:         TestFrameworkSocket.write(encoding, "flag encoding");
>> 
>> I don't see a need to use socket here, it will significantly simplify the code, the failure analysis, and reproducing if we just save prepared flags into a file w/ a well-known location (e.g. passed as an argument/property to `TestFrameworkPrepareFlags`), and when used command-line argument file (`@-file`) to pass these flags to the test VM.
>
> Okay, yes it would make it easier. But the socket can be kept for the communication between the test VM and the driver VM?

I don't have a strong opinion here. let's start w/ what you have now, we can always change it later if we find that its complexity doesn't bring much value.

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

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

From chagedorn at openjdk.java.net  Sun May  2 21:03:03 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Sun, 2 May 2021 21:03:03 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <nEnfA07eeT8NU0-Wo1lBP-SU3k31AHEfDWXD1fRGz5I=.96eb98e5-ea77-43bb-a695-8dcc993b9101@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
 <P2gEb7CfJxQ2_r__JrTrgXwYbufQp5wubTvIquL3RHk=.7c6e49b9-e0f4-4575-ab74-65c80ab68e08@github.com>
 <nEnfA07eeT8NU0-Wo1lBP-SU3k31AHEfDWXD1fRGz5I=.96eb98e5-ea77-43bb-a695-8dcc993b9101@github.com>
Message-ID: <U_i7urNFg47758geyiAbKEv2l5RQb82HGOGaSrXBepo=.4015347b-a3b4-40cd-9c08-d5532e2a6ff4@github.com>

On Sun, 2 May 2021 15:51:43 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Okay, yes it would make it easier. But the socket can be kept for the communication between the test VM and the driver VM?
>
> I don't have a strong opinion here. let's start w/ what you have now, we can always change it later if we find that its complexity doesn't bring much value.

Sounds good. I'll push an update with the changes tomorrow. Thanks for your review!

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

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

From iklam at openjdk.java.net  Mon May  3 05:28:56 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 3 May 2021 05:28:56 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <KzwDEgUVriRAFQh04-s_TG0R6XbIIwuiJLpwNqcnbQM=.5f975fad-fa60-4113-a597-75d03e2708da@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

The CDS changes look reasonable to me.

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

Marked as reviewed by iklam (Reviewer).

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

From iklam at openjdk.java.net  Mon May  3 05:33:13 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 3 May 2021 05:33:13 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v12]
In-Reply-To: <MTIgjVhALOGwsFtoiyOWn00wXZ999QCfHy57HGWkILU=.91dbdbe2-e202-4fc3-a31c-9817985fac06@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <MTIgjVhALOGwsFtoiyOWn00wXZ999QCfHy57HGWkILU=.91dbdbe2-e202-4fc3-a31c-9817985fac06@github.com>
Message-ID: <Ora5JGs_TSjmDqgg-WJGbkUghbk1608BtAI70kYHwb0=.9a4ad357-c4c5-42a8-9b0a-4b4fa0d76919@github.com>

On Fri, 30 Apr 2021 15:25:43 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>>      "java.lang.invoke.Invokers$Holder",
>>      "java.lang.invoke.DirectMethodHandle$Holder",
>>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>>      "java.lang.invoke.LambdaForm$Holder"
>>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
>> 
>>   Tests: tier1,tier2,tier3,tier4
>>   
>>   Thanks
>>   Yumin
>
> Yumin Qi 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:
> 
>  - Removed macro for exception handling, removed checking exception after reload class
>  - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493
>  - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom
>  - Merge branch 'master' into jdk-8255493
>  - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493
>  - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive
>  - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index
>  - Merge branch 'master' into jdk-8255493
>  - Restore filemap.[ch]pp
>  - Remove unnecessary file header including
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/859cafde...95d68855

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/lambdaFormInvokers.cpp line 142:

> 140:     memcpy(buf, (char*)h_bytes->byte_at_addr(0), len);
> 141:     ClassFileStream st((u1*)buf, len, NULL, ClassFileStream::verify);
> 142:     reload_class(class_name, st, THREAD);

`reload_class(class_name, st, THREAD);` should be `reload_class(class_name, st, CHECK);`. If an error happens inside there, it means `CDS.generateLambdaFormHolderClasses()` has generated a bad classfile, or we have hit an OOM. In either case, we should report the error back to the caller.

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

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

From rkennke at openjdk.java.net  Mon May  3 11:06:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 3 May 2021 11:06:53 GMT
Subject: RFR: 8261527: Record page size used for underlying mapping in
 ReservedSpace
In-Reply-To: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
References: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
Message-ID: <or7XKtcDsSvxZqpYbT4FWw43rDzwkRfzz4UbBa0ejso=.ed162eb4-a97a-48f3-b83c-2d5f737c495d@github.com>

On Thu, 29 Apr 2021 20:38:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.
> 
> The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 
> 
> There are two changes in behavior:
> * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
> * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.
> 
> **Testing**
> Mach5 tier1-4 and a lot of local testing.

Looks good to me.

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

Marked as reviewed by rkennke (Reviewer).

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

From iwalulya at openjdk.java.net  Mon May  3 13:08:51 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 3 May 2021 13:08:51 GMT
Subject: RFR: 8261527: Record page size used for underlying mapping in
 ReservedSpace
In-Reply-To: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
References: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
Message-ID: <N7qedosTDRS0wq7TnBBWFnpTFGNKFs6jn78ap9xn85E=.6e8ac6c0-d3a2-45b1-8daa-f4c78193e11c@github.com>

On Thu, 29 Apr 2021 20:38:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.
> 
> The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 
> 
> There are two changes in behavior:
> * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
> * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.
> 
> **Testing**
> Mach5 tier1-4 and a lot of local testing.

lgtm!

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

Marked as reviewed by iwalulya (Committer).

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

From vlivanov at openjdk.java.net  Mon May  3 13:09:08 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 3 May 2021 13:09:08 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation [v2]
In-Reply-To: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
Message-ID: <T3ff6JvKp3NrpE338Mzgzt8En_VMqZXtXERnWUOsSqo=.e515417a-b6d6-4acc-a2eb-7d94173c94c5@github.com>

> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
> 
> It served quite well for many years, but it accumulated significant complexity
> to support different corner cases over time and inevitable evolution of the JVM
> stretched the whole approach way too much (to the point where it become almost
> impossible to extend the analysis any further).
> 
> It turns out the root problem is the decision to reimplement method resolution
> and method selection logic from scratch and to perform it on JVM internal
> representation. It makes it very hard to reason about correctness and the
> implementation becomes sensitive to changes in internal representation.
> 
> So, the main motivation for the redesign is twofold: 
>  * reduce maintenance burden and increase confidence in the code;
>  * unlock some long-awaited enhancements.
> 
> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
> any possible enhancements are deliberately kept out of scope for the current PR.
> (It does deliver a bit of minor enhancements front as the changes in
> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
> of the other changes and was not the goal of the current work.)
> 
> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
> and relies on vtable/itable information to detect target method for every
> subclass it visits. It removes all the complexity associated with method
> resolution and method selection logic and leaves only essential logic to prepare for method selection.
> 
> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
> Instead of supporting not yet linked case, it is simply ignored. It is safe to
> skip them (treat as "effectively non-concrete") since it is guaranteed there
> are no instances created yet. But it requires VM to check dependencies once a
> class is linked.
> 
> I ended up with 2 separate dependency validation passes (when class is loaded
> and when it is linked). To avoid duplicated work, only dependencies
> which may be affected by class initialization state change
> (`unique_concrete_method_4`) are visited. 
> 
> (I experimented with merging passes into a single pass (delay the pass until
> linkage is over), but it severely affected other class-related dependencies and
> relevant optimizations.code.)
> 
> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
> 
> Old implementation is kept intact for now (will be removed later) to:
>   - JVMCI hasn't been migrated to the new implementation yet;
>   - enable verification that 2 implementations (old and new) agree on the results;
>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
> 
> Testing:
> - [x] hs-tier1 - hs-tier9
> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
> - [x] performance testing
>   
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision:

 - Improve comments
 - Use vm.opt.final.UseVtableBasedCHA

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3727/files
  - new: https://git.openjdk.java.net/jdk/pull/3727/files/3063f97d..02f615b2

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

  Stats: 14 lines in 2 files changed: 7 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3727/head:pull/3727

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

From vlivanov at openjdk.java.net  Mon May  3 13:46:11 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 3 May 2021 13:46:11 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation [v3]
In-Reply-To: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
Message-ID: <IKCm66ampWHbpHOLCOlrnvYSK1EqeSULkJ0vNQgqHWE=.65c0f313-6f08-4d17-ae57-52ad09b74068@github.com>

> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
> 
> It served quite well for many years, but it accumulated significant complexity
> to support different corner cases over time and inevitable evolution of the JVM
> stretched the whole approach way too much (to the point where it become almost
> impossible to extend the analysis any further).
> 
> It turns out the root problem is the decision to reimplement method resolution
> and method selection logic from scratch and to perform it on JVM internal
> representation. It makes it very hard to reason about correctness and the
> implementation becomes sensitive to changes in internal representation.
> 
> So, the main motivation for the redesign is twofold: 
>  * reduce maintenance burden and increase confidence in the code;
>  * unlock some long-awaited enhancements.
> 
> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
> any possible enhancements are deliberately kept out of scope for the current PR.
> (It does deliver a bit of minor enhancements front as the changes in
> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
> of the other changes and was not the goal of the current work.)
> 
> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
> and relies on vtable/itable information to detect target method for every
> subclass it visits. It removes all the complexity associated with method
> resolution and method selection logic and leaves only essential logic to prepare for method selection.
> 
> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
> Instead of supporting not yet linked case, it is simply ignored. It is safe to
> skip them (treat as "effectively non-concrete") since it is guaranteed there
> are no instances created yet. But it requires VM to check dependencies once a
> class is linked.
> 
> I ended up with 2 separate dependency validation passes (when class is loaded
> and when it is linked). To avoid duplicated work, only dependencies
> which may be affected by class initialization state change
> (`unique_concrete_method_4`) are visited. 
> 
> (I experimented with merging passes into a single pass (delay the pass until
> linkage is over), but it severely affected other class-related dependencies and
> relevant optimizations.code.)
> 
> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
> 
> Old implementation is kept intact for now (will be removed later) to:
>   - JVMCI hasn't been migrated to the new implementation yet;
>   - enable verification that 2 implementations (old and new) agree on the results;
>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
> 
> Testing:
> - [x] hs-tier1 - hs-tier9
> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
> - [x] performance testing
>   
> Thanks!

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

  Improve comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3727/files
  - new: https://git.openjdk.java.net/jdk/pull/3727/files/02f615b2..11276e26

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

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

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

From vladimir.x.ivanov at oracle.com  Mon May  3 13:51:29 2021
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 3 May 2021 16:51:29 +0300
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <c11b803e-d538-f891-1386-026dcc71e285@oracle.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
 <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
 <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>
 <Dg6AXFfNxSwYmqVI8aImJW3L6pybePpH318ExXMV8WU=.06b513c9-b338-415a-a20e-b5bbf24fd04a@github.com>
 <f11750cc-be1f-580c-cbcb-38c7d06fa736@oracle.com>
 <B31DD694-3576-47CC-953E-DDB94BB91CA3@oracle.com>
 <c11b803e-d538-f891-1386-026dcc71e285@oracle.com>
Message-ID: <acb67c3f-6fe2-0a2e-695d-e411867ba6fe@oracle.com>

Thanks for your feedback, Igor and David.

>> I meant both: in a generic sense, meaning we won't properly document, 
>> advertise it or claim it as supported; and changing its type to 
>> EXPERIMENTAL, so it will be somewhat harder for people to switch it.
> 
> Both forms are as hard to switch to as both must be unlocked. But 
> semantically this is not an experimental flag IMO.

I agree.

> Regardless, if the intent is to allow the flag to be used to restore 
> legacy behaviour, then that legacy behaviour must be tested. We don't 
> have to run thousands of tests with the flag disabled, just something 
> representative enough to give us confidence that the code has not 
> bit-rotted.

Yes, it makes perfect sense to test that -XX:-UseVtableBasedCHA is usable.

I'd like to point out that new implementation exercise old 
implementation [1] to verify that there's an agreement on the result.

So, maybe just a smoke test is enough here.

Best regards,
Vladimir Ivanov

[1] src/hotspot/share/code/dependencies.cpp:

Method* Dependencies::find_unique_concrete_method(InstanceKlass* ctxk, 
Method* m, Klass* resolved_klass, Method* resolved_method) {
...
   // Old CHA conservatively reports concrete methods in abstract classes
   // irrespective of whether they have concrete subclasses or not.
#ifdef ASSERT
   Klass*  uniqp = NULL;
   Method* uniqm = Dependencies::find_unique_concrete_method(ctxk, m, 
&uniqp);
   assert(uniqm == NULL || uniqm == fm ||
          uniqm->method_holder()->is_abstract() ||
          (fm == NULL && uniqm != NULL && uniqp != NULL && 
!InstanceKlass::cast(uniqp)->is_linked()),
          "sanity");
#endif // ASSERT


>>> On May 1, 2021, at 3:03 PM, David Holmes <david.holmes at oracle.com 
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> On 2/05/2021 1:39 am, Igor Ignatyev wrote:
>>>> On Fri, 30 Apr 2021 22:10:02 GMT, Vladimir Kozlov <kvn at openjdk.org 
>>>> <mailto:kvn at openjdk.org>> wrote:
>>>>>> I'm fine with both approaches.
>>>>>>
>>>>>> Explicitly setting the flag looked to me more robust and clearer 
>>>>>> communicating the intent. But if you prefer `@requires`, I'll use it.
>>>>>
>>>>> Let hear @iignatev opinion.
>>>> from my point of view, `@requires` is clearer and also eliminates 
>>>> "wasted" execution (if someone tries to run this test w/ 
>>>> `-XX:-UseVtableBasedCHA`), so I'd prefer if we use it.
>>>> I have a more generic comment about `UseVtableBasedCHA`. I 
>>>> understand the desire to introduce a flag to switch back to the old 
>>>> implementation, but I'm somewhat concern that it adds a new 
>>>> dimension into configuration space that won't be covered by our 
>>>> existing tests (w/ the test which exercises interesting parts of the 
>>>> related code is inapplicable) and isn't part of our regular test 
>>>> configurations. Can we make it an experimental flag (w/ vtable-based 
>>>> CHA still being enabled by default)? this way, the quality bar for 
>>>> the old implementation will be somewhat lower, yet the end-users 
>>>> will still be able to return to the old implementation if it, for 
>>>> some reason, works better in their use-cases.
>>>
>>> Did you mean "experimental" in a generic sense or actually change it 
>>> from DIAGNOSTIC to EXPERIMENTAL? If the latter then I don't agree 
>>> this is an experimental flag, it is diagnostic. But either way the 
>>> testing requirements are the same if we expect to tell end users to 
>>> try this flag if they hit an problem - the flag has to be known to be 
>>> functional, so we will have to expand the test coverage.
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> -- Igor
>>>> -------------
>>>> PR:https://git.openjdk.java.net/jdk/pull/3727 
>>>> <https://git.openjdk.java.net/jdk/pull/3727>
>>

From eric.caspole at oracle.com  Mon May  3 15:09:21 2021
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Mon, 3 May 2021 11:09:21 -0400
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2]
In-Reply-To: <WsvrpwCdr1F6qPdBDbibdxS9pzWQ7CRUyY131cbqQqU=.77bc4155-6a83-4a02-9fe9-a4b2ff42ca25@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <WsvrpwCdr1F6qPdBDbibdxS9pzWQ7CRUyY131cbqQqU=.77bc4155-6a83-4a02-9fe9-a4b2ff42ca25@github.com>
Message-ID: <88a1900d-1bf5-8dff-7b08-4df985d37375@oracle.com>

Hi Xubo, could you please make your JMH, noted below, conform to the 
others in, say, test/micro/org/openjdk/bench/java/util/ and it to to 
your PR. The JMH is useful work too and others could reuse it later.
Thanks,
Eric


On 4/30/21 3:57 PM, Xubo Zhang wrote:
>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>>
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>>
>> The optimization shows ~5x improvement.
>>
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>>
>>
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>
>    refactor adler32 algorithm to a new file x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and some other issues
>
> -------------
>
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/3806/files
>    - new: https://git.openjdk.java.net/jdk/pull/3806/files/c2b5a126..9d8e0230
>
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=01
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=00-01
>
>    Stats: 387 lines in 4 files changed: 210 ins; 169 del; 8 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806
>
> PR: https://git.openjdk.java.net/jdk/pull/3806


From github.com+168222+mgkwill at openjdk.java.net  Mon May  3 16:31:00 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 3 May 2021 16:31:00 GMT
Subject: Integrated: 8265491: Math Signum optimization for x86
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <p07aOSQI5p0OkxetN1-uu_XGMRTJmhAk-4kBH9H1mz0=.25fcae6f-5b2d-4f7d-9842-4d6a89c06042@github.com>

On Mon, 19 Apr 2021 23:00:47 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  ns/op
> 
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

This pull request has now been integrated.

Changeset: ff65920c
Author:    Marcus G K Williams <marcus.williams at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff65920cd17e7e862b182524e2151784e26a079c
Stats:     218 lines in 7 files changed: 212 ins; 1 del; 5 mod

8265491: Math Signum optimization for x86

Reviewed-by: jiefu, jbhateja, neliasso

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

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

From xubo.zhang at intel.com  Mon May  3 16:41:22 2021
From: xubo.zhang at intel.com (Zhang, Xubo)
Date: Mon, 3 May 2021 16:41:22 +0000
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2]
In-Reply-To: <88a1900d-1bf5-8dff-7b08-4df985d37375@oracle.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <WsvrpwCdr1F6qPdBDbibdxS9pzWQ7CRUyY131cbqQqU=.77bc4155-6a83-4a02-9fe9-a4b2ff42ca25@github.com>
 <88a1900d-1bf5-8dff-7b08-4df985d37375@oracle.com>
Message-ID: <DM6PR11MB34687857D548B7AF290DA0269B5B9@DM6PR11MB3468.namprd11.prod.outlook.com>

Hi Eric,
The jmh micro http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java is from Pengfei Li, shared as part of JDK-8216259 aarch64 optimization. Maybe Pengfei can contribute to the OpenJDK? 

Best regards,
Xubo

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of eric.caspole at oracle.com
Sent: Monday, May 3, 2021 8:09 AM
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2]

Hi Xubo, could you please make your JMH, noted below, conform to the others in, say, test/micro/org/openjdk/bench/java/util/ and it to to your PR. The JMH is useful work too and others could reuse it later.
Thanks,
Eric


On 4/30/21 3:57 PM, Xubo Zhang wrote:
>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>>
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>>
>> The optimization shows ~5x improvement.
>>
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units 
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op 
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op 
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op 
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op 
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op 
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op 
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op 
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op 
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>>
>>
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units 
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op 
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op 
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op 
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op 
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op 
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op 
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>
>    refactor adler32 algorithm to a new file 
> x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and 
> some other issues
>
> -------------
>
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/3806/files
>    - new: 
> https://git.openjdk.java.net/jdk/pull/3806/files/c2b5a126..9d8e0230
>
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=01
>   - incr: 
> https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=00-01
>
>    Stats: 387 lines in 4 files changed: 210 ins; 169 del; 8 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk 
> pull/3806/head:pull/3806
>
> PR: https://git.openjdk.java.net/jdk/pull/3806


From minqi at openjdk.java.net  Mon May  3 16:46:02 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 3 May 2021 16:46:02 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v12]
In-Reply-To: <Ora5JGs_TSjmDqgg-WJGbkUghbk1608BtAI70kYHwb0=.9a4ad357-c4c5-42a8-9b0a-4b4fa0d76919@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <MTIgjVhALOGwsFtoiyOWn00wXZ999QCfHy57HGWkILU=.91dbdbe2-e202-4fc3-a31c-9817985fac06@github.com>
 <Ora5JGs_TSjmDqgg-WJGbkUghbk1608BtAI70kYHwb0=.9a4ad357-c4c5-42a8-9b0a-4b4fa0d76919@github.com>
Message-ID: <6EbiRVkG5EfKcbNPG_MpthL0aV3WTbPWCWOAH4S43zM=.3216d0d7-241a-420a-abc8-cc13524dd892@github.com>

On Mon, 3 May 2021 05:28:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi 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:
>> 
>>  - Removed macro for exception handling, removed checking exception after reload class
>>  - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493
>>  - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom
>>  - Merge branch 'master' into jdk-8255493
>>  - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493
>>  - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive
>>  - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index
>>  - Merge branch 'master' into jdk-8255493
>>  - Restore filemap.[ch]pp
>>  - Remove unnecessary file header including
>>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/a3c65bfb...95d68855
>
> src/hotspot/share/cds/lambdaFormInvokers.cpp line 142:
> 
>> 140:     memcpy(buf, (char*)h_bytes->byte_at_addr(0), len);
>> 141:     ClassFileStream st((u1*)buf, len, NULL, ClassFileStream::verify);
>> 142:     reload_class(class_name, st, THREAD);
> 
> `reload_class(class_name, st, THREAD);` should be `reload_class(class_name, st, CHECK);`. If an error happens inside there, it means `CDS.generateLambdaFormHolderClasses()` has generated a bad classfile, or we have hit an OOM. In either case, we should report the error back to the caller.

Thanks, it should be a check here.

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

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

From eric.caspole at oracle.com  Mon May  3 16:59:18 2021
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Mon, 3 May 2021 12:59:18 -0400
Subject: [External] : RE: RFR: 8266332: Adler32 intrinsic for x86 64-bit
 platforms [v2]
In-Reply-To: <DM6PR11MB34687857D548B7AF290DA0269B5B9@DM6PR11MB3468.namprd11.prod.outlook.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <WsvrpwCdr1F6qPdBDbibdxS9pzWQ7CRUyY131cbqQqU=.77bc4155-6a83-4a02-9fe9-a4b2ff42ca25@github.com>
 <88a1900d-1bf5-8dff-7b08-4df985d37375@oracle.com>
 <DM6PR11MB34687857D548B7AF290DA0269B5B9@DM6PR11MB3468.namprd11.prod.outlook.com>
Message-ID: <a52b33ce-b507-dbf3-0110-374ece39f020@oracle.com>

Xubo,
thanks for clarifying that. Pengfei please consider to contribute this 
JMH ;)
Eric



On 5/3/21 12:41 PM, Zhang, Xubo wrote:
> Hi Eric,
> The jmh micro http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java is from Pengfei Li, shared as part of JDK-8216259 aarch64 optimization. Maybe Pengfei can contribute to the OpenJDK?
>
> Best regards,
> Xubo
>
> -----Original Message-----
> From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of eric.caspole at oracle.com
> Sent: Monday, May 3, 2021 8:09 AM
> To: hotspot-dev at openjdk.java.net
> Subject: Re: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2]
>
> Hi Xubo, could you please make your JMH, noted below, conform to the others in, say, test/micro/org/openjdk/bench/java/util/ and it to to your PR. The JMH is useful work too and others could reuse it later.
> Thanks,
> Eric
>
>
> On 4/30/21 3:57 PM, Xubo Zhang wrote:
>>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>>>
>>> For the following benchmark:
>>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>>>
>>> The optimization shows ~5x improvement.
>>>
>>> Base:
>>> Benchmark (count) Mode Cnt Score Error Units
>>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>>>
>>>
>>> With patch:
>>> Benchmark (count) Mode Cnt Score Error Units
>>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>     refactor adler32 algorithm to a new file
>> x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and
>> some other issues
>>
>> -------------
>>
>> Changes:
>>     - all: https://git.openjdk.java.net/jdk/pull/3806/files
>>     - new:
>> https://git.openjdk.java.net/jdk/pull/3806/files/c2b5a126..9d8e0230
>>
>> Webrevs:
>>    - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=01
>>    - incr:
>> https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=00-01
>>
>>     Stats: 387 lines in 4 files changed: 210 ins; 169 del; 8 mod
>>     Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
>>     Fetch: git fetch https://git.openjdk.java.net/jdk
>> pull/3806/head:pull/3806
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3806


From minqi at openjdk.java.net  Mon May  3 17:18:13 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 3 May 2021 17:18:13 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v13]
In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
Message-ID: <ToAQiQUAFryES1ZR03XmYnuaq8eIMisdnVs03Ss5E9A=.5d518469-e411-452c-99ce-886e57381f69@github.com>

> Hi, Please review
> 
>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>      "java.lang.invoke.Invokers$Holder",
>      "java.lang.invoke.DirectMethodHandle$Holder",
>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>      "java.lang.invoke.LambdaForm$Holder"
>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
> 
>   Tests: tier1,tier2,tier3,tier4
>   
>   Thanks
>   Yumin

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

  LambdaFormInvokers::reload should take CHECK

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3611/files
  - new: https://git.openjdk.java.net/jdk/pull/3611/files/95d68855..86247422

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

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

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

From iklam at openjdk.java.net  Mon May  3 17:37:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 3 May 2021 17:37:07 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v13]
In-Reply-To: <ToAQiQUAFryES1ZR03XmYnuaq8eIMisdnVs03Ss5E9A=.5d518469-e411-452c-99ce-886e57381f69@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <ToAQiQUAFryES1ZR03XmYnuaq8eIMisdnVs03Ss5E9A=.5d518469-e411-452c-99ce-886e57381f69@github.com>
Message-ID: <f8Je_mkeh3GcSi_NIPmUvZFMAVoiE2AGeJCA7F5YmYA=.2891e440-1f65-4874-a64a-706baaecd12d@github.com>

On Mon, 3 May 2021 17:18:13 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>>      "java.lang.invoke.Invokers$Holder",
>>      "java.lang.invoke.DirectMethodHandle$Holder",
>>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>>      "java.lang.invoke.LambdaForm$Holder"
>>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
>> 
>>   Tests: tier1,tier2,tier3,tier4
>>   
>>   Thanks
>>   Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   LambdaFormInvokers::reload should take CHECK

LGTM. Just a small nit about comments.

src/hotspot/share/cds/lambdaFormInvokers.hpp line 44:

> 42:   static void append_filtered(char* line);
> 43:   // All exceptions except for OOM will be suppressed in the fucntion, the
> 44:   // non-OOM failure should not affect normal archiving.

The above comments should be removed, since we do throw exceptions if the generated classfiles are invalid.

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

Marked as reviewed by iklam (Reviewer).

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

From chagedorn at openjdk.java.net  Mon May  3 17:42:53 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 17:42:53 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
Message-ID: <7n-HUaVnogF7L6lfbamFlUcvFb1jEB7zGwSf8dB5dsw=.131617ed-5a18-4615-b1d1-bbc3eb6c3cc0@github.com>

On Fri, 30 Apr 2021 19:02:37 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls
>>  - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings
>
> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 984:
> 
>> 982:     private final String hotspotPidFileName;
>> 983: 
>> 984:     JVMOutput(OutputAnalyzer oa, Scenario scenario, ProcessBuilder process) {
> 
> instead of passing a ProcessBuilder, you can either pass a command-line or better just past prepared flags, and make it JVMOutput's (you will need a better name) responsibility for executing the process, creating OutputAnalyzer, etc. 
> 
> Suggestion:
> 
>     JVMOutput(List<String> cmds, Scenario scenario) {
>         var pb = ProcessTools.createJavaProcessBuilder(cmds);
>         try {
>             // Calls 'main' of TestFrameworkExecution to run all specified tests with commands 'cmds'.
>             // Use executeProcess instead of executeTestJvm as we have already added the JTreg VM and
>             // Java options in prepareTestVMFlags().
>             this.oa = ProcessTools.executeProcess(process);
>         } catch (Exception e) {
>             throw new TestFrameworkException("Error while executing Test VM", e);
>         }
>         this.cmd = pb.command();
>         ...
> 
> 
> and then runTest will be smth like
> 
>     private void runTestVM(List<String> additionalFlags) {
>           List<String> cmds = prepareTestVMFlags(additionalFlags);
>           socket.start();
>           JVMOutput output = new JVMOutput(cmds, scenario);
>           ...

I did a refactoring and introduced new classes `FlagVMProcess` and `TestVMProcess`. I also did a renaming of `TestFrameworkPrepareFlags` -> `FlagVM` and `TestFrameworkExecution` -> `TestVM` to make it more clear whats going on.

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

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

From chagedorn at openjdk.java.net  Mon May  3 17:42:51 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 17:42:51 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v8]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <MKGNLdyoI92XyTUDKvxmEr9IYWbft6vIxVMi63VaUBY=.a1f49455-248c-4dfc-b11b-8aaf4216add2@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with four additional commits since the last revision:

 - Remove TestFramework: both runWithScenarios, both runWithHelperClasses, and one runWithFlags method to make interface cleaner/simpler, update internal tests accordingly
 - Minor improvements, comment fixes, and test fixes
 - Rename TestFrameworkPrepareFlags -> FlagVM and rename TestFrameworkExecution -> TestVM
 - Apply review comments: Extract Test classes into own files, extract Flag and Test VM processes into own class, replace socket-based flag VM communication with file-based and clean up socket usage of test VM, fix useless processing of hotspot-pid files if no IR rules are applied

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/90a0064d..d6c72ec6

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

  Stats: 4113 lines in 31 files changed: 2056 ins; 1938 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

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

From chagedorn at openjdk.java.net  Mon May  3 17:42:53 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 17:42:53 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <7n-HUaVnogF7L6lfbamFlUcvFb1jEB7zGwSf8dB5dsw=.131617ed-5a18-4615-b1d1-bbc3eb6c3cc0@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
 <7n-HUaVnogF7L6lfbamFlUcvFb1jEB7zGwSf8dB5dsw=.131617ed-5a18-4615-b1d1-bbc3eb6c3cc0@github.com>
Message-ID: <uUba-f4OCp0nt_YiO089NFrWFGPeF5cnEbNLT3DCYQw=.3409d59a-221e-4688-9723-9841685f3296@github.com>

On Mon, 3 May 2021 17:34:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 984:
>> 
>>> 982:     private final String hotspotPidFileName;
>>> 983: 
>>> 984:     JVMOutput(OutputAnalyzer oa, Scenario scenario, ProcessBuilder process) {
>> 
>> instead of passing a ProcessBuilder, you can either pass a command-line or better just past prepared flags, and make it JVMOutput's (you will need a better name) responsibility for executing the process, creating OutputAnalyzer, etc. 
>> 
>> Suggestion:
>> 
>>     JVMOutput(List<String> cmds, Scenario scenario) {
>>         var pb = ProcessTools.createJavaProcessBuilder(cmds);
>>         try {
>>             // Calls 'main' of TestFrameworkExecution to run all specified tests with commands 'cmds'.
>>             // Use executeProcess instead of executeTestJvm as we have already added the JTreg VM and
>>             // Java options in prepareTestVMFlags().
>>             this.oa = ProcessTools.executeProcess(process);
>>         } catch (Exception e) {
>>             throw new TestFrameworkException("Error while executing Test VM", e);
>>         }
>>         this.cmd = pb.command();
>>         ...
>> 
>> 
>> and then runTest will be smth like
>> 
>>     private void runTestVM(List<String> additionalFlags) {
>>           List<String> cmds = prepareTestVMFlags(additionalFlags);
>>           socket.start();
>>           JVMOutput output = new JVMOutput(cmds, scenario);
>>           ...
>
> I did a refactoring and introduced new classes `FlagVMProcess` and `TestVMProcess`. I also did a renaming of `TestFrameworkPrepareFlags` -> `FlagVM` and `TestFrameworkExecution` -> `TestVM` to make it more clear whats going on.

I did a refactoring and introduced new classes `FlagVMProcess` and `TestVMProcess`. I also did a renaming of `TestFrameworkPrepareFlags` -> `FlagVM` and `TestFrameworkExecution` -> `TestVM` to make it more clear whats going on.

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

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

From chagedorn at openjdk.java.net  Mon May  3 17:42:53 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 17:42:53 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <U_i7urNFg47758geyiAbKEv2l5RQb82HGOGaSrXBepo=.4015347b-a3b4-40cd-9c08-d5532e2a6ff4@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
 <P2gEb7CfJxQ2_r__JrTrgXwYbufQp5wubTvIquL3RHk=.7c6e49b9-e0f4-4575-ab74-65c80ab68e08@github.com>
 <nEnfA07eeT8NU0-Wo1lBP-SU3k31AHEfDWXD1fRGz5I=.96eb98e5-ea77-43bb-a695-8dcc993b9101@github.com>
 <U_i7urNFg47758geyiAbKEv2l5RQb82HGOGaSrXBepo=.4015347b-a3b4-40cd-9c08-d5532e2a6ff4@github.com>
Message-ID: <WvpSrZ0Aq4eWr0EttMMtk-ac8brGhOIxdkugsnmMqVg=.62077f44-7d4b-4434-bbee-ba3b49b69d8b@github.com>

On Sun, 2 May 2021 20:59:46 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> I don't have a strong opinion here. let's start w/ what you have now, we can always change it later if we find that its complexity doesn't bring much value.
>
> Sounds good. I'll push an update with the changes tomorrow. Thanks for your review!

I moved to a file-based approach for the flag VM and cleaned the socket up for the sole usage for the test VM.

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

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

From chagedorn at openjdk.java.net  Mon May  3 17:42:54 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 17:42:54 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <Iv_wApDfqdfY2muggzWqm4QumlHY7FZC3FnqIDUG4fs=.cac90f16-5bc4-4f0f-895f-05cd3aa4cc9b@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
 <Iv_wApDfqdfY2muggzWqm4QumlHY7FZC3FnqIDUG4fs=.cac90f16-5bc4-4f0f-895f-05cd3aa4cc9b@github.com>
Message-ID: <aAWiJbAvXcqrI50EAZU-Nq0pUF7Ko64aJ6xuJBLWMho=.41c97d9b-6a01-44d3-b89b-9f740c41e575@github.com>

On Fri, 30 Apr 2021 18:22:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestInfo.java line 57:
>> 
>>> 55:      * allowing a compilation on the requested level in {@link Test#compLevel()}.
>>> 56:      *
>>> 57:      * @return {@code true} if the framework compiled the test;
>> 
>> as in `RunInfo`:
>> s/compiled/skipped compilation of/
>
> btw, do we really need these methods in both `RunInfo` and `TestInfo`?

Yes, they are implemented slightly differently.

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

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

From minqi at openjdk.java.net  Mon May  3 17:49:53 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 3 May 2021 17:49:53 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v13]
In-Reply-To: <f8Je_mkeh3GcSi_NIPmUvZFMAVoiE2AGeJCA7F5YmYA=.2891e440-1f65-4874-a64a-706baaecd12d@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <ToAQiQUAFryES1ZR03XmYnuaq8eIMisdnVs03Ss5E9A=.5d518469-e411-452c-99ce-886e57381f69@github.com>
 <f8Je_mkeh3GcSi_NIPmUvZFMAVoiE2AGeJCA7F5YmYA=.2891e440-1f65-4874-a64a-706baaecd12d@github.com>
Message-ID: <qw2Yt2CUHRgE8Wg2OIWJES9LtSzNJQlSJDXufkPqh_s=.ad033631-fc8f-46c2-a8ab-0e62fd6eae59@github.com>

On Mon, 3 May 2021 17:30:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   LambdaFormInvokers::reload should take CHECK
>
> src/hotspot/share/cds/lambdaFormInvokers.hpp line 44:
> 
>> 42:   static void append_filtered(char* line);
>> 43:   // All exceptions except for OOM will be suppressed in the fucntion, the
>> 44:   // non-OOM failure should not affect normal archiving.
> 
> The above comments should be removed, since we do throw exceptions if the generated classfiles are invalid.

Will update, thanks!

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

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

From chagedorn at openjdk.java.net  Mon May  3 17:53:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 17:53:56 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <8m3dztYNNjO9ZHKSoyH3-YOtwFbKpMyn8WPgnxZRV-Q=.a07c3878-4567-4c43-b732-515fa750a6b2@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>
 <gxsA__SaOXZ2CYH2QMYVPIRiodtR-_HJv4n3s7VsAOA=.75227295-f0f8-4055-a29a-5d5fd3a28a68@github.com>
 <zbToJ5_pj6ysv-TUUD0oYpWacEvz0oUn2_CYDhHcJj4=.58f0dac0-8224-465c-9da0-da7970e91248@github.com>
 <8m3dztYNNjO9ZHKSoyH3-YOtwFbKpMyn8WPgnxZRV-Q=.a07c3878-4567-4c43-b732-515fa750a6b2@github.com>
Message-ID: <CoUTnT1xf3Va9k_3mj8Fv0L6DXZvIcFq6JDl0_ytNJw=.32ca9f79-d368-421f-a6d5-9bde83eaa698@github.com>

On Mon, 26 Apr 2021 19:16:17 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>>> > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
>>> > * the same goes for `README.html` generated from `README.md`
>>> 
>>> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk?
>>> 
>>> > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
>>> > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
>>> 
>>> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?
>> 
>> `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often.
>> 
>> Thanks,
>> -- Igor
>
>> There is no decision, yet, (and open for discussion) about the location and package name for the framework and the framework internal tests. After discussing it offline with @iignatev, we think there are basically two good options:
>> 
>> 1. Leave the framework in `/test/lib` and put the framework internal tests into `/test/lib-test`:
>>    
>>    * Pros: Only need to specify `@library /test/lib` in a JTreg test; the framework internal tests are run in tier1 before any other tests are run which depend on the framework ensuring correctness.
>>    * Cons: Clarity: The framework is intended to be used for HotSpot tests only (thus not exactly the right location in `/test/lib`); the framework internal tests might be run too often as part of tier1 (trade-off ensuring correctness vs. execution time).
>> 2. Move the framework to `/test/hotspot/jtreg/testlibrary`, put the framework internal tests into `/test/hotspot/jtreg/testlibrary_tests`, and use package name `hotspot.test.lib.ir_framework`:
>>    
>>    * Pros: Clarity: The framework is only used for HotSpot tests (mainly compiler tests but could also be used for other tests).
>>    * Cons: A JTreg test needs to additionally specify `/testlibrary/ir_framework` like `@library /testlibrary/ir_framework /test/lib`; the framework internal tests are run more seldomly as part of `:hotspot_misc` (trade-off, see cons of first option).
>> 
> 
> there is also 3rd alternative, move the framework to `/test/hotspot/jtreg/compiler/` and use `compiler.ir_framework` or `compiler.lib.ir_framework` as the package name. that will make it even clearer that this is a compiler-specific library, and its users are going to be in `/test/hotspot/jtreg/compiler/`. I understand that there can be some runtime (or other) tests that might benefit from this library, but in the end, they won't be clear runtime tests, so `t/h/j/compiler` might be a better location for them anyways. the `@library` tag will still have to contain two paths, but these will be usual paths as in many compiler tests : `@library / /test/lib`.
> the tests can be placed in `/test/hotspot/jtreg/testlibrary_tests` as in the 2nd option, with the same trade-off.
> 
> -- Igor

I did a slightly bigger refactoring reflecting the review comments by @iignatev:
- Extracting classes into own Java files
- Class renamings
- Moving to file-based communication for the flag VM to simplify the socket usage for the test VM (required some clean-ups)
- Removed some `TestFramework` public methods as discussed earlier in this PR.

Missing (I will tackle this tomorrow):
- separating classes into own (sub)packages
- trying to move tests to `/test/hotspot/jtreg/testlibrary_tests` and the framework to `/test/hotspot/jtreg/compiler` as suggested in an earlier comment

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

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

From chagedorn at openjdk.java.net  Mon May  3 18:10:57 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 3 May 2021 18:10:57 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
Message-ID: <o_QRSw0uXynwXJz97bWPpa2kKNfDFSPRnmLCJZPrANw=.32695056-1664-49ca-a1cd-9c157b36642b@github.com>

On Fri, 30 Apr 2021 19:12:08 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> I've reviewed all the files but `examples` and `tests`, for them I'd actually recommend you to put `examples` into `tests` (possible in a subdir), and just update readme to say that the examples can be found in test directory.

Thanks a lot Igor! I'll consider to move the `examples` as well tomorrow.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestVMException.java line 34:
> 
>> 32:     TestVMException(String exceptionInfo) {
>> 33:         super("There were one or multiple errors. Please check stderr for more information.");
>> 34:         this.exceptionInfo = exceptionInfo;
> 
> why can't this info be stored as `Throwable::message`?

There were errors in some cases when the message was too long. Thus, I used a separate field for it which I then print to the stderr.

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

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

From minqi at openjdk.java.net  Mon May  3 18:14:10 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 3 May 2021 18:14:10 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v14]
In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
Message-ID: <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>

> Hi, Please review
> 
>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>      "java.lang.invoke.Invokers$Holder",
>      "java.lang.invoke.DirectMethodHandle$Holder",
>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>      "java.lang.invoke.LambdaForm$Holder"
>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
> 
>   Tests: tier1,tier2,tier3,tier4
>   
>   Thanks
>   Yumin

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

  Removed incorrect comment for regenerate_holder_classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3611/files
  - new: https://git.openjdk.java.net/jdk/pull/3611/files/86247422..61675bde

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=12-13

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May  3 18:34:53 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 3 May 2021 18:34:53 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2]
In-Reply-To: <Acx5fGEjK0CxiLfmUkCS2wMecU_IRt8PA5Grf6nqyWg=.952e1c44-128c-4112-bd80-babd05d7935a@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <WsvrpwCdr1F6qPdBDbibdxS9pzWQ7CRUyY131cbqQqU=.77bc4155-6a83-4a02-9fe9-a4b2ff42ca25@github.com>
 <Acx5fGEjK0CxiLfmUkCS2wMecU_IRt8PA5Grf6nqyWg=.952e1c44-128c-4112-bd80-babd05d7935a@github.com>
Message-ID: <PHps1RIKMAf4G310rfjz5MnJFk0Z5gOjEsCEhkt-_dQ=.8d69b72d-2c3d-40fb-bfb0-d0367c69be47@github.com>

On Fri, 30 Apr 2021 20:02:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor adler32 algorithm to a new file x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and some other issues
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 3248:
> 
>> 3246: 
>> 3247: void MacroAssembler::vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len, Register scratch_reg) {
>> 3248:   // Used in sign-bit flipping with aligned address.
> 
> You could remove the spurious comment here.

removed

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May  3 18:41:54 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 3 May 2021 18:41:54 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v3]
In-Reply-To: <aDlf2dIN26NyGSn7URPuEGX-ceqTtd6Xv3UZ6aSpD9c=.21a7a8d0-e8bc-48a9-bd6d-b12fd34e28dc@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <aDlf2dIN26NyGSn7URPuEGX-ceqTtd6Xv3UZ6aSpD9c=.21a7a8d0-e8bc-48a9-bd6d-b12fd34e28dc@github.com>
Message-ID: <qmAIhOQcaW9VoPWRwOiEMeuXd9gxPGHZzD_YfhJA8ho=.3e8f708c-5619-4f30-9afb-11feea65a8e2@github.com>

On Fri, 30 Apr 2021 00:21:57 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   set flag UseAdler32Intrinsics differently to based on 64 or 32-bit modes.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5812:
> 
>> 5810:       StubCodeMark mark(this, "StubRoutines", "updateBytesAdler32");
>> 5811: 
>> 5812:       address start = __ pc();
> 
> The algorithm part can go into macroAssembler_x86_adler.cpp with Intel copyright (see macroAssembler_x86_sha.cpp).

macroAssembler_x86_adler.cpp added

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May  3 18:41:51 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 3 May 2021 18:41:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2]
In-Reply-To: <Acx5fGEjK0CxiLfmUkCS2wMecU_IRt8PA5Grf6nqyWg=.952e1c44-128c-4112-bd80-babd05d7935a@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <WsvrpwCdr1F6qPdBDbibdxS9pzWQ7CRUyY131cbqQqU=.77bc4155-6a83-4a02-9fe9-a4b2ff42ca25@github.com>
 <Acx5fGEjK0CxiLfmUkCS2wMecU_IRt8PA5Grf6nqyWg=.952e1c44-128c-4112-bd80-babd05d7935a@github.com>
Message-ID: <sbl_rcNGKmsxh-1Qu27E4j5fdC58OywkmHPxmlpXpRU=.f8b4fb7c-0cdf-483d-9732-97c26e745692@github.com>

On Fri, 30 Apr 2021 20:11:44 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor adler32 algorithm to a new file x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and some other issues
>
> src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 32:
> 
>> 30: #include "macroAssembler_x86.hpp"
>> 31: 
>> 32: 
> 
> The updateBytesAdler32 should be under #ifdef _LP64, #endif.

#ifdef _LP64 ... #endif  added

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5824:
> 
>> 5822:       __ enter(); // required for proper stackwalking of RuntimeStub frame
>> 5823: 
>> 5824:       __ vmovdqu(yshuf0, ExternalAddress((address) StubRoutines::x86::_adler32_shuf0_table));
> 
> For vmovdqu also it is good to be explicit with scratch register.

added scratch register to vmovdqu

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

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

From vlivanov at openjdk.java.net  Mon May  3 18:45:07 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 3 May 2021 18:45:07 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation [v4]
In-Reply-To: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
Message-ID: <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>

> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
> 
> It served quite well for many years, but it accumulated significant complexity
> to support different corner cases over time and inevitable evolution of the JVM
> stretched the whole approach way too much (to the point where it become almost
> impossible to extend the analysis any further).
> 
> It turns out the root problem is the decision to reimplement method resolution
> and method selection logic from scratch and to perform it on JVM internal
> representation. It makes it very hard to reason about correctness and the
> implementation becomes sensitive to changes in internal representation.
> 
> So, the main motivation for the redesign is twofold: 
>  * reduce maintenance burden and increase confidence in the code;
>  * unlock some long-awaited enhancements.
> 
> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
> any possible enhancements are deliberately kept out of scope for the current PR.
> (It does deliver a bit of minor enhancements front as the changes in
> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
> of the other changes and was not the goal of the current work.)
> 
> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
> and relies on vtable/itable information to detect target method for every
> subclass it visits. It removes all the complexity associated with method
> resolution and method selection logic and leaves only essential logic to prepare for method selection.
> 
> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
> Instead of supporting not yet linked case, it is simply ignored. It is safe to
> skip them (treat as "effectively non-concrete") since it is guaranteed there
> are no instances created yet. But it requires VM to check dependencies once a
> class is linked.
> 
> I ended up with 2 separate dependency validation passes (when class is loaded
> and when it is linked). To avoid duplicated work, only dependencies
> which may be affected by class initialization state change
> (`unique_concrete_method_4`) are visited. 
> 
> (I experimented with merging passes into a single pass (delay the pass until
> linkage is over), but it severely affected other class-related dependencies and
> relevant optimizations.code.)
> 
> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
> 
> Old implementation is kept intact for now (will be removed later) to:
>   - JVMCI hasn't been migrated to the new implementation yet;
>   - enable verification that 2 implementations (old and new) agree on the results;
>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
> 
> Testing:
> - [x] hs-tier1 - hs-tier9
> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
> - [x] performance testing
>   
> Thanks!

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

  Cover abstract method case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3727/files
  - new: https://git.openjdk.java.net/jdk/pull/3727/files/11276e26..2ee8a779

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

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May  3 18:45:19 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 3 May 2021 18:45:19 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v4]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <Sz8tRgP1uH1laoa9BP87uBhKlYFJKabegUbNLaREufI=.f1904037-fae3-42e7-bd00-2cf1f67837fb@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> For the following benchmark:
> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> 
> The optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

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

  changed copyright year to 2021 in macroAssembler_x86_adler.cpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/57ec0b8c..bc60f308

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

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

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

From psandoz at openjdk.java.net  Mon May  3 21:43:54 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 3 May 2021 21:43:54 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
Message-ID: <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>

On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> This work is part of second round of incubation of the Vector API.
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8261663
>> 
>> Please review.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge master
>  - remove whitespace
>  - Merge master
>  - Small fix
>  - cleanup
>  - x86 short vector math optimization for Vector API

Tier 1 to 3 tests pass for the default set of build profiles.

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

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

From sviswanathan at openjdk.java.net  Mon May  3 22:07:54 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 3 May 2021 22:07:54 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v4]
In-Reply-To: <Sz8tRgP1uH1laoa9BP87uBhKlYFJKabegUbNLaREufI=.f1904037-fae3-42e7-bd00-2cf1f67837fb@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <Sz8tRgP1uH1laoa9BP87uBhKlYFJKabegUbNLaREufI=.f1904037-fae3-42e7-bd00-2cf1f67837fb@github.com>
Message-ID: <CPMUEYsORvfSO5GKcUf_PzQga-utB89Kd04B4PT3am8=.7277a494-f8c2-479f-b462-44fb4b8eb733@github.com>

On Mon, 3 May 2021 18:45:19 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed copyright year to 2021 in macroAssembler_x86_adler.cpp

src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 82:

> 80:       cmpptr(data, end);
> 81:       jcc(Assembler::aboveEqual, SKIP_LOOP_1A);
> 82: 

align(32) is needed here.

src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 113:

> 111:       vpaddd(xa, xa, xtmp0, Assembler::AVX_256bit);
> 112:       vpaddd(xb, xb, xtmp1, Assembler::AVX_256bit);
> 113:       vpaddd(xsa, xsa, xtmp2, Assembler::AVX_256bit);

Should Assembler::AVX_128bit here.

src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 179:

> 177:       movdl(rax, xb);
> 178:       addl(b_d, rax);
> 179: 

align(32) is needed here.

src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 183:

> 181:       movzbl(rax, Address(data, 0)); //movzx   eax, byte[data]
> 182:       addl(a_d, rax);
> 183:       incl(data);

data is a pointer, incl(data) should be either incptr(data) or addptr(data, 1);

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

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

From sviswanathan at openjdk.java.net  Mon May  3 22:11:59 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 3 May 2021 22:11:59 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
 <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
Message-ID: <F1OREM_iteRA4rV-5Mg-p3Ya1T2nbyNhtOw6FgDleOU=.326d86a0-28a2-43e4-a234-8dc7e407a0b4@github.com>

On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge master
>>  - remove whitespace
>>  - Merge master
>>  - Small fix
>>  - cleanup
>>  - x86 short vector math optimization for Vector API
>
> Tier 1 to 3 tests pass for the default set of build profiles.

@PaulSandoz Thanks a lot for running through the tests.

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

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

From xliu at openjdk.java.net  Mon May  3 23:30:20 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 3 May 2021 23:30:20 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v10]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with three additional commits since the last revision:

 - Implement the global option -Xlog:async per CSR.
   
   The old options -XX:+AsyncLogging and the output option are both removed.
   This patch also deliver the zero-cost promise. ie. No AsyncLog thread will be
   launched if async_mode is not eanbled.
 - Reimplement Accurate Decorations for AsyncLogging.
   
   LogDecorations defines a copy constructutor. Each log message copys it
   once.
 - Revert "Accurate Decorations for AsyncLogging."
   
   This reverts commit 1f06be3126f829055aff3720aea7e82544fd0c3a.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/e2d6f9e0..98ae33fb

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

  Stats: 265 lines in 12 files changed: 75 ins; 141 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Tue May  4 00:53:17 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Tue, 4 May 2021 00:53:17 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v5]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> For the following benchmark:
> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> 
> The optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

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

  added align; replace incl with addptr

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/bc60f308..172d7c63

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

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Tue May  4 01:03:50 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Tue, 4 May 2021 01:03:50 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86
In-Reply-To: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
Message-ID: <V3E1cfSu5f2K4X8u9wz3TgqvXshgTHO7FEsx1RNxJAs=.912838e0-8f48-4f96-9862-c9af48a0aab2@github.com>

On Fri, 2 Apr 2021 23:14:44 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Hi Gerard,
Although we don't have benchmark data yet, serialize is the recommended alternative vs. using CPUID. Also, in the virtual machine environment, serialize provides full/fast serialization without causing VMEXIT

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

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

From jbhateja at openjdk.java.net  Tue May  4 05:58:54 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 4 May 2021 05:58:54 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v5]
In-Reply-To: <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
Message-ID: <kqiX2AFj3d_1eoJqRZpFGAJ8bGPVJeEdJ7QUhg42t4I=.9fdf06f3-fa5a-4b1f-becc-ed885b9ded77@github.com>

On Tue, 4 May 2021 00:53:17 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added align; replace incl with addptr

src/hotspot/cpu/x86/assembler_x86.cpp line 7859:

> 7857: void Assembler::vbroadcastf128(XMMRegister dst, Address src, int vector_len) {
> 7858:   assert(VM_Version::supports_avx(), "");
> 7859:   assert(vector_len == AVX_256bit || vector_len == AVX_512bit, "");

If you expect vector length 512 bits then above assert should also check for evex mode.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 3248:

> 3246: 
> 3247: void MacroAssembler::vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len, Register scratch_reg) {
> 3248:   assert((UseAVX > 0), "SSE mode requires address alignment 16 bytes");

Assert message needs re-composition.

src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 85:

> 83:       align(32);
> 84:       bind(SLOOP1A);
> 85:       vbroadcastf128(ydata, Address(data, 0), Assembler::AVX_256bit);

Loop operates over integral data (double word), shouldn't it be safe to use double broadcasting instruction to save which domain switchover penalty (not sure if broadcasting will causes domain switch over though), but this is happening in the main vector loop so being conservative.

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

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

From xliu at openjdk.java.net  Tue May  4 06:46:52 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 4 May 2021 06:46:52 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v10]
In-Reply-To: <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>
Message-ID: <LfgloUfdD9AtVbvK3uYlV55C0qfEvkbI1T0zgjS0SKc=.d6b9f272-c686-4048-82ba-f5b71347747f@github.com>

On Mon, 3 May 2021 23:30:20 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Implement the global option -Xlog:async per CSR.
>    
>    The old options -XX:+AsyncLogging and the output option are both removed.
>    This patch also deliver the zero-cost promise. ie. No AsyncLog thread will be
>    launched if async_mode is not eanbled.
>  - Reimplement Accurate Decorations for AsyncLogging.
>    
>    LogDecorations defines a copy constructutor. Each log message copys it
>    once.
>  - Revert "Accurate Decorations for AsyncLogging."
>    
>    This reverts commit 1f06be3126f829055aff3720aea7e82544fd0c3a.

Hi, Reviewers, 

May I ask to review this PR? I make it comply with the CSR. A global flag `-Xlog:async` will enable async logging. 
By default, this flag is off.  Now it's pure zero-cost by default.  HotSpot even doesn't launch asynclog thread. 

thanks,
--lx

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

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

From alanb at openjdk.java.net  Tue May  4 08:23:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 4 May 2021 08:23:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v7]
In-Reply-To: <xHNHdhBRHVEHfehNhvq_oli_DrFP2sG-A4f6vM9UV7U=.db4711de-f37c-485a-a775-e57bdb4b7493@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <xHNHdhBRHVEHfehNhvq_oli_DrFP2sG-A4f6vM9UV7U=.db4711de-f37c-485a-a775-e57bdb4b7493@github.com>
Message-ID: <bssH3m473NBfk63ZTc9Azp4vMeUGbOZaXtzWsxShWpo=.21ff0918-9ee8-4b15-be37-b9d5975f22ba@github.com>

On Fri, 30 Apr 2021 15:20:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert bad change in benchmark copyright
>  - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value

Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right?

src/java.base/share/classes/java/lang/Module.java line 115:

> 113: 
> 114:     // is this module a native module
> 115:     private volatile boolean enableNativeAccess = false;

Can you drop "= false", it's not needed and I don't think we want a volatile-write here.
Also the comment may date from a previous iteration as there isn't any concept of a "native module".

src/java.base/share/classes/java/lang/System.java line 2346:

> 2344:             public boolean isEnableNativeAccess(Module m) {
> 2345:                 return m.isEnableNativeAccess();
> 2346:             }

Can you move this up so they are with the other Module methods?

src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34:

> 32: import java.util.Set;
> 33: 
> 34: public final class IllegalNativeAccessChecker {

Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access.

src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 47:

> 45:     private static IllegalNativeAccessChecker checker;
> 46: 
> 47:     static Collection<String> enableNativeAccessModules() {

I assume this can be changed to Iterable<String> as you don't want anything outside of this class changing the collection.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 889:

> 887:             } else {
> 888:                 // silently skip.
> 889:                 // warnUnknownModule(ENABLE_NATIVE_ACCESS, name);

Maybe for later but the other options do emit a warning when unknown module is specified. If the decoding of this command line option is moved to ModuleBootstrap then most of this class will go away and you will be able to use warnUnknownModule.

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 113:

> 111:         if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) {
> 112:             String moduleName = module.isNamed()?  module.getName() : "UNNAMED";
> 113:             throw new IllegalCallerException("Illegal native access from module: " + moduleName);

"UNNAMED" is a bit inconsistent with the other exception messages. Can you just use Module::toString here instead, meaning "Illegal native access from " + module ?

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

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

From aph at openjdk.java.net  Tue May  4 09:00:03 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 4 May 2021 09:00:03 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v5]
In-Reply-To: <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
Message-ID: <XQWn6cFMENE4ZoCxqgngaWzo1iHirraRKdz-fThKeZY=.8c05c1b1-28c2-448f-8c95-e3d8f92b181d@github.com>

On Tue, 4 May 2021 00:53:17 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added align; replace incl with addptr

So I'm wondering. With JEP 414, the Vector API, do we need to keep writing hand-carved assembly for these things? It would be very instructive to see how well we can do with Java code; and if the Vector API isn't good enough, we need to know that.

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

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

From sjohanss at openjdk.java.net  Tue May  4 09:03:53 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 4 May 2021 09:03:53 GMT
Subject: RFR: 8261527: Record page size used for underlying mapping in
 ReservedSpace
In-Reply-To: <or7XKtcDsSvxZqpYbT4FWw43rDzwkRfzz4UbBa0ejso=.ed162eb4-a97a-48f3-b83c-2d5f737c495d@github.com>
References: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
 <or7XKtcDsSvxZqpYbT4FWw43rDzwkRfzz4UbBa0ejso=.ed162eb4-a97a-48f3-b83c-2d5f737c495d@github.com>
Message-ID: <Xi5Aok_OoPOqo8nQQjpXw7jjUqkbUA9WVw21O2g-PIo=.3ef8f22e-8294-496b-9921-9abe73179b52@github.com>

On Mon, 3 May 2021 11:04:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.
>> 
>> The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 
>> 
>> There are two changes in behavior:
>> * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
>> * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.
>> 
>> **Testing**
>> Mach5 tier1-4 and a lot of local testing.
>
> Looks good to me.

Thanks for the reviews @rkennke and @walulyai.

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

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

From sjohanss at openjdk.java.net  Tue May  4 09:03:54 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 4 May 2021 09:03:54 GMT
Subject: Integrated: 8261527: Record page size used for underlying mapping in
 ReservedSpace
In-Reply-To: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
References: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
Message-ID: <G0y1_yD04nGH9gNR8BWujE0IAupNs_W4-0ZOczS8DI0=.5b3cd671-19e2-4173-8e81-c930e43a0899@github.com>

On Thu, 29 Apr 2021 20:38:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.
> 
> The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 
> 
> There are two changes in behavior:
> * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
> * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.
> 
> **Testing**
> Mach5 tier1-4 and a lot of local testing.

This pull request has now been integrated.

Changeset: 141cc2f2
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/141cc2f2a35abdce48397071e2ce7ea862cf5755
Stats:     135 lines in 20 files changed: 18 ins; 26 del; 91 mod

8261527: Record page size used for underlying mapping in ReservedSpace

Reviewed-by: rkennke, iwalulya

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

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

From mcimadamore at openjdk.java.net  Tue May  4 09:54:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 May 2021 09:54:04 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v7]
In-Reply-To: <bssH3m473NBfk63ZTc9Azp4vMeUGbOZaXtzWsxShWpo=.21ff0918-9ee8-4b15-be37-b9d5975f22ba@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <xHNHdhBRHVEHfehNhvq_oli_DrFP2sG-A4f6vM9UV7U=.db4711de-f37c-485a-a775-e57bdb4b7493@github.com>
 <bssH3m473NBfk63ZTc9Azp4vMeUGbOZaXtzWsxShWpo=.21ff0918-9ee8-4b15-be37-b9d5975f22ba@github.com>
Message-ID: <G_Mn39yz1dm4WJ1rFVEBGzyc0p420xLem0jurQ8IH30=.6ed57e9b-5aa8-4c61-a095-e6f59814aba5@github.com>

On Tue, 4 May 2021 08:20:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right?

No, at the moment it is not possible to enable native access programmatically. We will explore something along those lines in the future.

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

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

From stuefe at openjdk.java.net  Tue May  4 09:54:58 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 4 May 2021 09:54:58 GMT
Subject: RFR: 8261527: Record page size used for underlying mapping in
 ReservedSpace
In-Reply-To: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
References: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
Message-ID: <OiCl2h4XPdr2rW3mnHY97SafElJHJx-2mOtvCWlLMO8=.716dec0d-b099-4dce-96bd-96a664efd089@github.com>

On Thu, 29 Apr 2021 20:38:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.
> 
> The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 
> 
> There are two changes in behavior:
> * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
> * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.
> 
> **Testing**
> Mach5 tier1-4 and a lot of local testing.

I see you were too fast for me :) 

Good patch. Much cleaner now.

Thanks, Thomas

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

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

From mcimadamore at openjdk.java.net  Tue May  4 10:06:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 May 2021 10:06:25 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v8]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <jLMf4AjHmKMa3JFEMZKrwTSozgVxoTeZtNaQKwmB8vM=.2e7be85a-1f32-48bc-a58d-969355d3bacf@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Remove redundant initializer in Module
 - Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/793ea5c5..6a659d87

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

  Stats: 19 lines in 3 files changed: 6 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From sjohanss at openjdk.java.net  Tue May  4 10:20:50 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 4 May 2021 10:20:50 GMT
Subject: RFR: 8261527: Record page size used for underlying mapping in
 ReservedSpace
In-Reply-To: <OiCl2h4XPdr2rW3mnHY97SafElJHJx-2mOtvCWlLMO8=.716dec0d-b099-4dce-96bd-96a664efd089@github.com>
References: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>
 <OiCl2h4XPdr2rW3mnHY97SafElJHJx-2mOtvCWlLMO8=.716dec0d-b099-4dce-96bd-96a664efd089@github.com>
Message-ID: <q0t0dxaSKZVAuCPb5AXPcGFYJcz_xA6jQGJ_tMbNpj8=.571b2a68-e97a-47c3-894d-c30f8f578063@github.com>

On Tue, 4 May 2021 09:52:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.
>> 
>> The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 
>> 
>> There are two changes in behavior:
>> * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
>> * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.
>> 
>> **Testing**
>> Mach5 tier1-4 and a lot of local testing.
>
> I see you were too fast for me :) 
> 
> Good patch. Much cleaner now.
> 
> Thanks, Thomas

Thanks @tstuefe =)

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

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

From rkennke at openjdk.java.net  Tue May  4 11:08:16 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 4 May 2021 11:08:16 GMT
Subject: RFR: 8266491: Remove resolve and obj_equals leftovers from
 BarrierSetAssembler
Message-ID: <lpcgFj_fzbl12jHFQ_mhy-1sCEQPBLIqdl4kSB-nPIw=.d3b3702d-ae75-40be-9c8b-9ef42e0ae760@github.com>

Shenandoah used to require resolve() and obj_equals() in its first incarnation in JDK12. This is long obsolete, and the corresponding code can be removed from BarrierSetAssembler. It also makes the code less confusing because obj_equals() and resolve() have both been rather clunky and given that they now do nothing (and there are other resolve* methods in BSA too), it's not even clear what they would be supposed to do. It also makes life easier for porters to other platforms.

Testing:
 - [x] Build x86_64, x86_32
 - [x] hotspot_gc_shenandoah
 - [ ] tier1, tier2
 - [ ] Build arm, aarch64 (by GH-actions)

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

Commit messages:
 - 8266491: Remove resolve and obj_equals leftovers from BarrierSetAssembler

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

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

From stuefe at openjdk.java.net  Tue May  4 11:28:35 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 4 May 2021 11:28:35 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
Message-ID: <Y8LxRWzGneJ2D4Kn7HQJHmGUjCwHjXzYjURTDGD0zEk=.640fb2ac-f8e7-4701-a850-6b1e77bac051@github.com>

On Thu, 29 Apr 2021 04:50:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.
> 
> Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in various data holder structures which all are named somewhat similarly and all do a very similar job. In particular, we have:
> 
> - MetaspaceSizesSnapshot (used for gc logs)
> - MetaspaceSnapshot (used in NMT)
> - MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
> - MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
> - CompressedKlassSpacePool and MetaspacePool (used for MXBeans)
> 
> As much as possible coding should be unified.
> 
> In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).
> 
> -----------------------
> 
> This patch introduces two new data holder structures:
> - `MetaspaceStats` holds reserved/committed/used counter
> - `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.
> 
> Furthermore, the patch introduces two new APIs in MetaspaceUtils:
> - `MetaspaceStats get_statistics(type)`
> - `MetaspaceCombinedStats get_combined_statistics()`
> The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.
> 
> The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:
> 
> - GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.
> 
> - NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
>    - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
>    - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
>    - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).
> 
> - jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
> 	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
> 	- I simplified the counter coding a lot. I think the complexity was not needed.
> 	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.
> 
> - `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 
> 
> - JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
> 	- I completely removed `MetaspaceSizes`
> 	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`
> 
> - MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.
> 
> - Added a simple gtest for the new APIs
> 
> Tests: 
> - manually executed hotspot tier1 tests
> - explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
> - SAP nightlies ran on all our platforms

@zhengyu123 : could you take a look at the NMT part of this change? Thanks!

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

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

From stuefe at openjdk.java.net  Tue May  4 11:28:35 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 4 May 2021 11:28:35 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
Message-ID: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>

There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.

Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in various data holder structures which all are named somewhat similarly and all do a very similar job. In particular, we have:

- MetaspaceSizesSnapshot (used for gc logs)
- MetaspaceSnapshot (used in NMT)
- MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
- MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
- CompressedKlassSpacePool and MetaspacePool (used for MXBeans)

As much as possible coding should be unified.

In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).

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

This patch introduces two new data holder structures:
- `MetaspaceStats` holds reserved/committed/used counter
- `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.

Furthermore, the patch introduces two new APIs in MetaspaceUtils:
- `MetaspaceStats get_statistics(type)`
- `MetaspaceCombinedStats get_combined_statistics()`
The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.

The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:

- GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.

- NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
   - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
   - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
   - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).

- jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
	- I simplified the counter coding a lot. I think the complexity was not needed.
	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.

- `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 

- JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
	- I completely removed `MetaspaceSizes`
	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`

- MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.

- Added a simple gtest for the new APIs

Tests: 
- manually executed hotspot tier1 tests
- explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
- SAP nightlies ran on all our platforms

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

Commit messages:
 - wip

Changes: https://git.openjdk.java.net/jdk/pull/3786/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3786&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251392
  Stats: 593 lines in 33 files changed: 193 ins; 304 del; 96 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3786/head:pull/3786

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

From tschatzl at openjdk.java.net  Tue May  4 11:38:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 4 May 2021 11:38:55 GMT
Subject: RFR: 8266491: Remove resolve and obj_equals leftovers from
 BarrierSetAssembler
In-Reply-To: <lpcgFj_fzbl12jHFQ_mhy-1sCEQPBLIqdl4kSB-nPIw=.d3b3702d-ae75-40be-9c8b-9ef42e0ae760@github.com>
References: <lpcgFj_fzbl12jHFQ_mhy-1sCEQPBLIqdl4kSB-nPIw=.d3b3702d-ae75-40be-9c8b-9ef42e0ae760@github.com>
Message-ID: <g__lbEmrJWfrgiBkUDwF2sijbZ78dS5ku5ylCip87EE=.6010116c-074b-42f5-9170-6bb6d830f687@github.com>

On Tue, 4 May 2021 11:01:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Shenandoah used to require resolve() and obj_equals() in its first incarnation in JDK12. This is long obsolete, and the corresponding code can be removed from BarrierSetAssembler. It also makes the code less confusing because obj_equals() and resolve() have both been rather clunky and given that they now do nothing (and there are other resolve* methods in BSA too), it's not even clear what they would be supposed to do. It also makes life easier for porters to other platforms.
> 
> Testing:
>  - [x] Build x86_64, x86_32
>  - [x] hotspot_gc_shenandoah
>  - [ ] tier1, tier2
>  - [ ] Build arm, aarch64 (by GH-actions)

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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

From mcimadamore at openjdk.java.net  Tue May  4 11:58:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 May 2021 11:58:22 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v9]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <OxblKjfavw-HmI0XKjCFadU3I9mBkXYTUVtFEQIliDc=.a40803e8-8bde-451f-8f2b-4f5b759ca483@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Tweak code some more
 - Use uniform naming convention for implementation metods in Module
 - Remove IllegalNativeAccessChecker

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/6a659d87..ead71078

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

  Stats: 169 lines in 5 files changed: 41 ins; 114 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From mcimadamore at openjdk.java.net  Tue May  4 12:05:16 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 May 2021 12:05:16 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v7]
In-Reply-To: <bssH3m473NBfk63ZTc9Azp4vMeUGbOZaXtzWsxShWpo=.21ff0918-9ee8-4b15-be37-b9d5975f22ba@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <xHNHdhBRHVEHfehNhvq_oli_DrFP2sG-A4f6vM9UV7U=.db4711de-f37c-485a-a775-e57bdb4b7493@github.com>
 <bssH3m473NBfk63ZTc9Azp4vMeUGbOZaXtzWsxShWpo=.21ff0918-9ee8-4b15-be37-b9d5975f22ba@github.com>
Message-ID: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com>

On Tue, 4 May 2021 08:12:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert bad change in benchmark copyright
>>  - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value
>
> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34:
> 
>> 32: import java.util.Set;
>> 33: 
>> 34: public final class IllegalNativeAccessChecker {
> 
> Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access.

I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas.

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

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

From mcimadamore at openjdk.java.net  Tue May  4 12:05:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 May 2021 12:05:15 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v10]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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

  Tweak comment in Module::enableNativeAccess

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/ead71078..2a31da40

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

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

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

From dholmes at openjdk.java.net  Tue May  4 12:08:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 4 May 2021 12:08:52 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v14]
In-Reply-To: <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>
Message-ID: <iNa-_P87wXXtVl9gKhqqNEndYe65ymWctZ7WuUB9dHw=.653bd9e7-d024-4070-9547-5593406f645d@github.com>

On Mon, 3 May 2021 18:14:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>>      "java.lang.invoke.Invokers$Holder",
>>      "java.lang.invoke.DirectMethodHandle$Holder",
>>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>>      "java.lang.invoke.LambdaForm$Holder"
>>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
>> 
>>   Tests: tier1,tier2,tier3,tier4
>>   
>>   Thanks
>>   Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed incorrect comment for regenerate_holder_classes

The TRAPS/CHECK usages seem okay now.

Thanks,
David

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

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

From tschatzl at openjdk.java.net  Tue May  4 12:21:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 4 May 2021 12:21:55 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

First pass, just comment suggestions for now.

src/hotspot/share/classfile/javaClasses.hpp line 119:

> 117:   static const uint8_t _deduplication_requested_mask = 1 << 1;
> 118: 
> 119:   static int flags_offset() { CHECK_INIT(_flags_offset); }

Maybe add some description about the injected `flags` field and its contents here.

src/hotspot/share/classfile/javaClasses.hpp line 152:

> 150:   static inline void set_value(oop string, typeArrayOop buffer);
> 151: 
> 152:   // Set the no_deduplication flag true.  This flag is sticky; once set it

Initially I was a bit confused of the use of "flag" here and that the field is called "flags". Maybe use "deduplication bit" here, or rename the "flags" field but feel free to ignore.

src/hotspot/share/classfile/javaClasses.hpp line 154:

> 152:   // Set the no_deduplication flag true.  This flag is sticky; once set it
> 153:   // never gets cleared.  This is set when a string is interned in the
> 154:   // StringTable, to prevent string deduplication from changing the string's

I think this information about the contents of the injected "flags" should be collected somewhere else as piecing together what fields "flags" has from different method documentation seems wrong.

src/hotspot/share/classfile/javaClasses.hpp line 170:

> 168:   static inline bool hash_is_set(oop string);
> 169:   static inline bool is_latin1(oop java_string);
> 170:   static inline bool no_deduplication(oop java_string);

That identifier is missing a verb to read better, but I do not have a good idea. Maybe it would be easier to use the negation of "no_deduplication", something like "may_deduplicate"?
Feel free to ignore.

src/hotspot/share/classfile/javaClasses.hpp line 171:

> 169:   static inline bool is_latin1(oop java_string);
> 170:   static inline bool no_deduplication(oop java_string);
> 171:   static inline bool deduplication_requested(oop java_string);

Having a verb at the beginning like `is_deduplication_requested` sounds better.

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 31:

> 29: //
> 30: // String deduplication aims to reduce the heap live-set by deduplicating
> 31: // identical instances of String so that they share the same backing byte

... by deduplicating instances of (java.lang.)String with identical backing byte array (the String's value).

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 69:

> 67: // arrays.  This permits reclamation of arrays that become unused.  This is
> 68: // separate from the request storage objects because dead count tracking is
> 69: // used by the table implementation as part of resizing decisions and for

s/table/string table? I.e. which table is referred to here?

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 84:

> 82: // interned string might later become a deduplication candidate through the
> 83: // normal GC discovery mechanism.  This is handled by setting the
> 84: // no_deduplication flag in a string before interning it.  A string with

s/string/String

Maybe:

s/This is handled.../Deduplication is prevented by setting the no_deduplication flag in the String before.../

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

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

From coleenp at openjdk.java.net  Tue May  4 12:39:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 4 May 2021 12:39:07 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
Message-ID: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>

Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.

Tested with tier1-6, tiers 7,8 are running and 98% passing.

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

Commit messages:
 - 8266497: Remove unnecessary EMCP liveness indication

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

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

From alanb at openjdk.java.net  Tue May  4 14:24:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 4 May 2021 14:24:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v10]
In-Reply-To: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com>
Message-ID: <ewSWtuXHNPlvup8icYRPsOCBDWkA5XhWyqE6HSz0C68=.ce6de58b-337a-4b6c-892c-eacce13a904d@github.com>

On Tue, 4 May 2021 12:05:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak comment in Module::enableNativeAccess

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 112:

> 110:         Module module = currentClass.getModule();
> 111:         if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) {
> 112:             throw new IllegalCallerException("Illegal native access from module: " + module);

You may want to drop "module" from the exception message as Module::toString is specified to return "module XXXX" or "unnamed module XXXX" so you'll end up duplication "module" in the message.

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

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

From alanb at openjdk.java.net  Tue May  4 14:24:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 4 May 2021 14:24:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v7]
In-Reply-To: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <xHNHdhBRHVEHfehNhvq_oli_DrFP2sG-A4f6vM9UV7U=.db4711de-f37c-485a-a775-e57bdb4b7493@github.com>
 <bssH3m473NBfk63ZTc9Azp4vMeUGbOZaXtzWsxShWpo=.21ff0918-9ee8-4b15-be37-b9d5975f22ba@github.com>
 <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com>
Message-ID: <CwHZRnoSdG1ZdoVDUxu-rivO7ktRQSvkw-Qy5QksuHc=.426c8489-22ae-47c6-8236-e36265e32573@github.com>

On Tue, 4 May 2021 12:01:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34:
>> 
>>> 32: import java.util.Set;
>>> 33: 
>>> 34: public final class IllegalNativeAccessChecker {
>> 
>> Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access.
>
> I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas.

Good, this looks much simpler now.

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

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

From mcimadamore at openjdk.java.net  Tue May  4 14:37:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 May 2021 14:37:25 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v11]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <CGw0xH8YNP2i8OHU-18VZItY6pH4g9zLpMH-pENGAgI=.f9f6a3ee-78b9-43e7-a598-858ba8f10044@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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

  Fix message string in Reflection::ensureNativeAccess

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/2a31da40..72eb9bbc

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

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

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

From github.com+71302734+amitdpawar at openjdk.java.net  Tue May  4 14:53:56 2021
From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar)
Date: Tue, 4 May 2021 14:53:56 GMT
Subject: RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen
 expansion [v4]
In-Reply-To: <F9gnZre_0t5YCXWy8GcoDb7bt-PvrRmpwHZ3KeRhMqE=.77b27cef-b3cb-4b8d-a3bf-1f58fe36094a@github.com>
References: <LhBCPXEt0MeOU3p8KjB79l3aa7N2TfDRkdmI8mZDkCM=.83f7a6c3-a48d-4f1a-b3f6-37780e150f97@github.com>
 <F9gnZre_0t5YCXWy8GcoDb7bt-PvrRmpwHZ3KeRhMqE=.77b27cef-b3cb-4b8d-a3bf-1f58fe36094a@github.com>
Message-ID: <b0bBoTsDqmo-ICAfpUBLf6L1jg-U7n3HiwlzLUHFIxI=.ac5ead7b-01a1-4a58-b903-cda7ba7c337f@github.com>

On Wed, 7 Apr 2021 15:22:10 GMT, Amit Pawar <github.com+71302734+amitdpawar at openjdk.org> wrote:

>> In case of ParallelGC, oldgen expansion can happen during promotion. Expanding thread will touch the pages and can't request for task execution as this GC thread is already executing a task. The expanding thread holds the lock on "ExpandHeap_lock" to resize the oldgen and other threads may wait for their turn. This is a blocking call.
>> 
>> This patch changes this behavior by adding another constructor in "MutexLocker" class to enable non blocking or try_lock operation. This way one thread will acquire the lock and other threads can join pretouch work. Threads failed to acquire the lock will join pretouch only when task is marked ready by expanding thread.
>> 
>> Following minimum expansion size are seen during expansion.
>> 1. 512KB without largepages and without UseNUMA.
>> 2. 64MB without largepages and with UseNUMA,
>> 3. 2MB (on x86)  with large pages and without UseNUMA,
>> 4. 64MB without large pages and with UseNUMA.
>> 
>> When Oldgen is expanding repeatedly with smaller size then this change wont help. For such cases, resize size should adapt to application demand to make use of this change. For example if application nature triggers 100 expansion with smaller sizes in same GC then it is better to increase the expansion size during each resize to reduce the number of resizes. If this patch is accepted then will plan to fix this case in another patch.
>> 
>> Jtreg all test passed.
>> 
>> Please review this change.
>
> Amit Pawar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This code is used for testing purpose and lock should be acquired with no
>   safepoint check as similar to earlier code.

Thanks for your reply and good to know that alternative implementation is possible. I will wait. Thanks

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

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

From minqi at openjdk.java.net  Tue May  4 15:17:55 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 4 May 2021 15:17:55 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v14]
In-Reply-To: <iNa-_P87wXXtVl9gKhqqNEndYe65ymWctZ7WuUB9dHw=.653bd9e7-d024-4070-9547-5593406f645d@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>
 <iNa-_P87wXXtVl9gKhqqNEndYe65ymWctZ7WuUB9dHw=.653bd9e7-d024-4070-9547-5593406f645d@github.com>
Message-ID: <rYOfjGOkH3KPkG3Q06y15pKWLpHlpsSfyhriCHMSN5c=.614b0976-06aa-494d-bf05-d6a22c60161c@github.com>

On Tue, 4 May 2021 12:05:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed incorrect comment for regenerate_holder_classes
>
> The TRAPS/CHECK usages seem okay now.
> 
> Thanks,
> David

@dholmes-ora Thanks for comment again. @calvinccheung @coleenp I need one more OK to push since this is not a trivial fix.

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

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

From rkennke at openjdk.java.net  Tue May  4 15:26:11 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 4 May 2021 15:26:11 GMT
Subject: RFR: 8266504: Remove leftovers from BarrierSetAssemblerC1
Message-ID: <DuVkQA0ZSqj83cpRrJqlvnYk1hwk8z-EAlwWbFdiOnc=.ba5d3b1b-d371-4a96-a61b-edf4af0fd242@github.com>

Earlier incarnation of Shenandoah required resolve() and naming of runtime calls. We can safely remove a bunch of obsolete code from BarrierSetC1.

Testing:
 - [x] hotspot_gc_shenandoah
 - [x] tier1
 - [x] tier2

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

Commit messages:
 - 8266504: Remove leftovers from BarrierSetAssemblerC1

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

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

From sviswanathan at openjdk.java.net  Tue May  4 15:37:52 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 4 May 2021 15:37:52 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v5]
In-Reply-To: <XQWn6cFMENE4ZoCxqgngaWzo1iHirraRKdz-fThKeZY=.8c05c1b1-28c2-448f-8c95-e3d8f92b181d@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
 <XQWn6cFMENE4ZoCxqgngaWzo1iHirraRKdz-fThKeZY=.8c05c1b1-28c2-448f-8c95-e3d8f92b181d@github.com>
Message-ID: <zxWCtt8xAY3BhBMeiwpjo9JtLTkTrFEwGzam8yqQkzA=.ef4bb76f-1f83-4cd6-9ac2-aedbfc418202@github.com>

On Tue, 4 May 2021 08:57:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added align; replace incl with addptr
>
> So I'm wondering. With JEP 414, the Vector API, do we need to keep writing hand-carved assembly for these things? It would be very instructive to see how well we can do with Java code; and if the Vector API isn't good enough, we need to know that.

@theRealAph Vector API is still incubator module and cannot be used to implement standard JRE till it is finalized and becomes a standard module.

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

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

From ccheung at openjdk.java.net  Tue May  4 15:40:55 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 4 May 2021 15:40:55 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v14]
In-Reply-To: <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>
Message-ID: <R46egp5igYTUXo3XEa6UsofYBvoYtcHQgoeIuOd7A2M=.8fdb2cc4-7a3c-4fc6-86aa-3ebbbce25549@github.com>

On Mon, 3 May 2021 18:14:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>>      "java.lang.invoke.Invokers$Holder",
>>      "java.lang.invoke.DirectMethodHandle$Holder",
>>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>>      "java.lang.invoke.LambdaForm$Holder"
>>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
>> 
>>   Tests: tier1,tier2,tier3,tier4
>>   
>>   Thanks
>>   Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed incorrect comment for regenerate_holder_classes

Latest version looks good. Just one nit.

Thanks,
Calvin

src/hotspot/share/cds/dynamicArchive.cpp line 350:

> 348:     ArchiveClassesAtExit = archive_name;
> 349:     if (Arguments::init_shared_archive_paths()) {
> 350:       DynamicArchive::dump(CHECK);

I think you can drop the `DynamicArchive::` in the above since it is called from the same class.

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

Marked as reviewed by ccheung (Reviewer).

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

From stuefe at openjdk.java.net  Tue May  4 15:49:53 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 4 May 2021 15:49:53 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v10]
In-Reply-To: <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>
Message-ID: <zmPx3YHn7bKE8mszIl21J0R7u2vTVQksCSxv7bTMa-A=.be0c7c76-4548-48a4-aa9b-5405f23ce76e@github.com>

On Mon, 3 May 2021 23:30:20 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Implement the global option -Xlog:async per CSR.
>    
>    The old options -XX:+AsyncLogging and the output option are both removed.
>    This patch also deliver the zero-cost promise. ie. No AsyncLog thread will be
>    launched if async_mode is not eanbled.
>  - Reimplement Accurate Decorations for AsyncLogging.
>    
>    LogDecorations defines a copy constructutor. Each log message copys it
>    once.
>  - Revert "Accurate Decorations for AsyncLogging."
>    
>    This reverts commit 1f06be3126f829055aff3720aea7e82544fd0c3a.

Hi Xin,

I put https://github.com/openjdk/jdk/pull/3855 up for review. Please take a look at it. It makes LogDecorations trivially copy-able, and it reduces its size by about a quarter too. With this patch I believe you can do without your new LogDecorations copy constructor as well as the deleted assignment op since the default copy constructor and assignment operator should work fine now.

I do not understand why you make the _tagset member in LogDecorations optional. Could you explain this?

Cheers, Thomas

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

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

From minqi at openjdk.java.net  Tue May  4 15:51:55 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 4 May 2021 15:51:55 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v14]
In-Reply-To: <R46egp5igYTUXo3XEa6UsofYBvoYtcHQgoeIuOd7A2M=.8fdb2cc4-7a3c-4fc6-86aa-3ebbbce25549@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
 <siwHBVSnrreKt5UxbUQ6vzb4aHZMYBjPk6tRs0deVNI=.d927715e-b99c-4585-b90d-d4de8762e194@github.com>
 <R46egp5igYTUXo3XEa6UsofYBvoYtcHQgoeIuOd7A2M=.8fdb2cc4-7a3c-4fc6-86aa-3ebbbce25549@github.com>
Message-ID: <HT2WJbHVZxUdqG8awOtQHh1dwAhiBkauj_kfR4KY0_U=.bbb9e002-a29a-43f7-835a-4ed45708df7f@github.com>

On Tue, 4 May 2021 15:37:49 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> I think you can drop the `DynamicArchive::` in the above since it is called from the same class.

Thanks. Will remove the DynamicArchive:: at push.

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

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

From chagedorn at openjdk.java.net  Tue May  4 15:53:26 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 4 May 2021 15:53:26 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v8]
In-Reply-To: <MKGNLdyoI92XyTUDKvxmEr9IYWbft6vIxVMi63VaUBY=.a1f49455-248c-4dfc-b11b-8aaf4216add2@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <MKGNLdyoI92XyTUDKvxmEr9IYWbft6vIxVMi63VaUBY=.a1f49455-248c-4dfc-b11b-8aaf4216add2@github.com>
Message-ID: <ZpbT031e7HQOMQK8-wp1ixR1eGMTaeD9O9hDvuTgn10=.6305f0a9-64cf-47d3-9b76-911888a72b78@github.com>

On Mon, 3 May 2021 17:42:51 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove TestFramework: both runWithScenarios, both runWithHelperClasses, and one runWithFlags method to make interface cleaner/simpler, update internal tests accordingly
>  - Minor improvements, comment fixes, and test fixes
>  - Rename TestFrameworkPrepareFlags -> FlagVM and rename TestFrameworkExecution -> TestVM
>  - Apply review comments: Extract Test classes into own files, extract Flag and Test VM processes into own class, replace socket-based flag VM communication with file-based and clean up socket usage of test VM, fix useless processing of hotspot-pid files if no IR rules are applied

As mentioned above, I moved the framework classes and tests and updated the packages. I also split the classes into subpackages to structure the code better.  A summary of the package structure can be found in the updated README file in section 5.

I put this PR on hold as I'm away until the end of the month.

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

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

From chagedorn at openjdk.java.net  Tue May  4 15:53:25 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 4 May 2021 15:53:25 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v9]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <PqaKCsAvDdmFfg1vcTvjG5DEjwjajKWD0J1PRPzbYLA=.81406790-be0c-41dd-b278-6af3fb52157e@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with three additional commits since the last revision:

 - Splitting classes into subpackages and updating README accordingly, fix bug with new line matching in lookbehind on Windows
 - Fix package names and fixing internal tests, examples and README file accordingly
 - Move framework to test/hotspot/jtreg/compiler/lib and tests to test/hotspot/jtreg/testlibrary_tests/compiler/lib/ir_framework

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/d6c72ec6..4424e01f

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

  Stats: 2150 lines in 78 files changed: 1009 ins; 968 del; 173 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

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

From aph at openjdk.java.net  Tue May  4 15:58:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 4 May 2021 15:58:59 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v5]
In-Reply-To: <XQWn6cFMENE4ZoCxqgngaWzo1iHirraRKdz-fThKeZY=.8c05c1b1-28c2-448f-8c95-e3d8f92b181d@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
 <XQWn6cFMENE4ZoCxqgngaWzo1iHirraRKdz-fThKeZY=.8c05c1b1-28c2-448f-8c95-e3d8f92b181d@github.com>
Message-ID: <bRUZBl7-sIlind34_DY4mMRg2ihS3rokJFF6mdvE4Qo=.13c13f74-347f-40b4-8ae8-d6e78ce5f6f0@github.com>

On Tue, 4 May 2021 08:57:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added align; replace incl with addptr
>
> So I'm wondering. With JEP 414, the Vector API, do we need to keep writing hand-carved assembly for these things? It would be very instructive to see how well we can do with Java code; and if the Vector API isn't good enough, we need to know that.

> @theRealAph Vector API is still incubator module and cannot be used to implement standard JRE till it is finalized and becomes a standard module.

Sure, I get that, and I suppose if we're desperate to have a vectorized intrinsic for Adler32 _right now_ this PR must go ahead right now. However, I'd be delighted to see the end of exquisitely hand-carved but hard-to-understand and hard-to-maintain assembly language, and it would be an excellent test for the coverage of the Vector API.

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

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

From coleenp at openjdk.java.net  Tue May  4 16:10:03 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 4 May 2021 16:10:03 GMT
Subject: RFR: 8266498: Make debug ps() call print_stack
Message-ID: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>

Fix ps() call print_stack.  Tested manually and with fastdebug and debug.  Also removed hsfind() because find() is the same thing and nobody's using dbx anymore (and the overload that made me add it might be long gone).
Tested with tier1 sanity.

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

Commit messages:
 - 8266498: Make debug ps() call print_stack
 - 8266498: Make debug ps() call print_stack

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

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

From psandoz at openjdk.java.net  Tue May  4 16:29:08 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 4 May 2021 16:29:08 GMT
Subject: RFR: 8266317: Vector API enhancements
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: <6XDATQRilzomvEwoFXNENdi4dWlYjrw0TLXNJPWs6Q0=.68f2de4f-a964-45ee-8bf2-a9720dfbff35@github.com>

On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

All tests pass for tier1,tier2,tier3 for build profiles linux-x64, linux-aarch64, macosx-x64, and windows-x64.

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

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

From psandoz at openjdk.java.net  Tue May  4 16:29:08 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 4 May 2021 16:29:08 GMT
Subject: RFR: 8266317: Vector API enhancements
Message-ID: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>

This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.

Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.

Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.

The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

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

Commit messages:
 - Minor clarifications to the specification.
 - 8266317: Vector API enhancements

Changes: https://git.openjdk.java.net/jdk/pull/3803/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266317
  Stats: 10002 lines in 121 files changed: 9070 ins; 190 del; 742 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803

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

From minqi at openjdk.java.net  Tue May  4 16:38:18 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 4 May 2021 16:38:18 GMT
Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes
 in CDS dynamic archive [v15]
In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
Message-ID: <L_NJYdRDYtOj4LTDUlyj_rDU_DQEN8JW8E7vPwQZjf8=.e3e8405c-669c-41f7-9009-ab6c3f95eb01@github.com>

> Hi, Please review
> 
>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>      "java.lang.invoke.Invokers$Holder",
>      "java.lang.invoke.DirectMethodHandle$Holder",
>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>      "java.lang.invoke.LambdaForm$Holder"
>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
> 
>   Tests: tier1,tier2,tier3,tier4
>   
>   Thanks
>   Yumin

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

  Remove unessential scope operator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3611/files
  - new: https://git.openjdk.java.net/jdk/pull/3611/files/61675bde..f8fff3fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=13-14

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

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

From rkennke at openjdk.java.net  Tue May  4 16:48:01 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 4 May 2021 16:48:01 GMT
Subject: RFR: 8266519: Cleanup resolve() leftovers from BarrierSet et al
Message-ID: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>

Shenandoah used to require a way to resolve oops, but it's long unused the the corresponding code in the access machinery is obsolete. Let's remove it.

Testing:
 - [x] hotspot_gc_shenandoah
 - [ ] tier1
 - [ ] tier2

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

Commit messages:
 - 8266519: Cleanup resolve() leftovers from BarrierSet et al

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

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

From stuefe at openjdk.java.net  Tue May  4 16:52:52 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 4 May 2021 16:52:52 GMT
Subject: RFR: 8266498: Make debug ps() call print_stack
In-Reply-To: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
References: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
Message-ID: <2MbsagSb57Fr-UgWO0U06X47lG9apTx1y8IAzC0yK3g=.386b438f-0a9a-40d2-ac89-20f9a86db04c@github.com>

On Tue, 4 May 2021 16:02:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix ps() call print_stack.  Tested manually and with fastdebug and debug.  Also removed hsfind() because find() is the same thing and nobody's using dbx anymore (and the overload that made me add it might be long gone).
> Tested with tier1 sanity.

Looks fine to me.

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

Marked as reviewed by stuefe (Reviewer).

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

From neliasso at openjdk.java.net  Tue May  4 17:14:51 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 4 May 2021 17:14:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v5]
In-Reply-To: <bRUZBl7-sIlind34_DY4mMRg2ihS3rokJFF6mdvE4Qo=.13c13f74-347f-40b4-8ae8-d6e78ce5f6f0@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <XKEfyXgcnWBYQpQnAUhtdV2b7jaLihMSoTvaYYgP1qE=.add6b630-fc67-4267-9143-b9a528b8208d@github.com>
 <XQWn6cFMENE4ZoCxqgngaWzo1iHirraRKdz-fThKeZY=.8c05c1b1-28c2-448f-8c95-e3d8f92b181d@github.com>
 <bRUZBl7-sIlind34_DY4mMRg2ihS3rokJFF6mdvE4Qo=.13c13f74-347f-40b4-8ae8-d6e78ce5f6f0@github.com>
Message-ID: <_HtwNK-Y3HSeXpPVNZRs7lzfvHhUrGu8uvAgVf18qsA=.1c9096c3-96bc-4217-8ee7-88cf34415d87@github.com>

On Tue, 4 May 2021 15:56:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > @theRealAph Vector API is still incubator module and cannot be used to implement standard JRE till it is finalized and becomes a standard module.
> 
> Sure, I get that, and I suppose if we're desperate to have a vectorized intrinsic for Adler32 _right now_ this PR must go ahead right now. However, I'd be delighted to see the end of exquisitely hand-carved but hard-to-understand and hard-to-maintain assembly language, and it would be an excellent test for the coverage of the Vector API.

We already have Adler32 implemented on aarch - so I think it is very reasonable to add it on x64 too. But I am very sympathetic to your general point about big chunks of handcrafted assembly.

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

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

From lfoltan at openjdk.java.net  Tue May  4 17:15:50 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Tue, 4 May 2021 17:15:50 GMT
Subject: RFR: 8266498: Make debug ps() call print_stack
In-Reply-To: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
References: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
Message-ID: <3NKzrouBd-Cc9X61GRL3rn8Tk-ZoKVrmRwD0J3dDc20=.5daeeff8-9b1e-45c4-ba89-7444057d02ae@github.com>

On Tue, 4 May 2021 16:02:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix ps() call print_stack.  Tested manually and with fastdebug and debug.  Also removed hsfind() because find() is the same thing and nobody's using dbx anymore (and the overload that made me add it might be long gone).
> Tested with tier1 sanity.

Looks good.
Lois

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

Marked as reviewed by lfoltan (Reviewer).

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

From minqi at openjdk.java.net  Tue May  4 17:21:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 4 May 2021 17:21:56 GMT
Subject: Integrated: 8255493: Support for pre-generated java.lang.invoke
 classes in CDS dynamic archive
In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com>
Message-ID: <2o4NPeF3qk3BVkFFt58QoNXevr4dCzzbWVscvpOsnJE=.a71dda66-485f-4393-8c46-6bb3b6a936e0@github.com>

On Wed, 21 Apr 2021 22:34:48 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> 
>   When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, 
>      "java.lang.invoke.Invokers$Holder",
>      "java.lang.invoke.DirectMethodHandle$Holder",
>      "java.lang.invoke.DelegatingMethodHandle$Holder",
>      "java.lang.invoke.LambdaForm$Holder"
>   which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>   (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
> 
>   Tests: tier1,tier2,tier3,tier4
>   
>   Thanks
>   Yumin

This pull request has now been integrated.

Changeset: 8b37d487
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8b37d4877087052e2ce721b795217feea24802b3
Stats:     281 lines in 11 files changed: 222 ins; 21 del; 38 mod

8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive

Reviewed-by: iklam, ccheung

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

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

From github.com+168222+mgkwill at openjdk.java.net  Tue May  4 17:59:56 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 4 May 2021 17:59:56 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v30]
In-Reply-To: <WY8gehBxfTA2BNvdp6CbdU8AiFPp5_VtySLfpr0KwsA=.8038b318-3785-4f1c-86f2-c0aa0d380e01@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <g9JpfS7APOwOQp2lVSVVQN9qgvZuq8ZEByVCwbKgPuo=.8d92f58c-38eb-4dff-8078-b45a7fbe30ab@github.com>
 <WY8gehBxfTA2BNvdp6CbdU8AiFPp5_VtySLfpr0KwsA=.8038b318-3785-4f1c-86f2-c0aa0d380e01@github.com>
Message-ID: <cTF3ZRcXn5UuSr94DWj6a0VbUTOm3ogL5FwkzVer1FE=.78067f88-a9d5-4a57-bf79-4e92cfea4c5d@github.com>

On Fri, 30 Apr 2021 07:48:12 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Filed [JDK-8266349](https://bugs.openjdk.java.net/browse/JDK-8266349) for passing page size down to `reserve_memory_special`. As I mentioned [here](https://github.com/openjdk/jdk/pull/1153/files#r623353767), if we do this change before this one. We should not have to care about anything but adding the available and configure page sizes to `os::_page_sizes`.

Thanks @kstefanj. Sounds like a clean way to go. Looking forward to seeing the code. Is this likely for JDK17 branch?

> src/hotspot/share/runtime/os.cpp line 1483:
> 
>> 1481:     for (size_t page_size = page_sizes().largest(); page_size != 0;
>> 1482:          page_size = page_sizes().next_smaller(page_size)) {
>> 1483:       if (page_size <= max_page_size && page_size > (size_t)vm_page_size()) {
> 
> Is this really needed?

Probably not. I am doublechecking with some testing.

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

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

From coleenp at openjdk.java.net  Tue May  4 20:05:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 4 May 2021 20:05:52 GMT
Subject: RFR: 8266498: Make debug ps() call print_stack
In-Reply-To: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
References: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
Message-ID: <Evh7EFpDephQ5ieefv7CPbuCQkE2OJBuqMovR9_1E0I=.6b490d60-9a45-4fc7-9b31-2a50a0c962f4@github.com>

On Tue, 4 May 2021 16:02:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix ps() call print_stack.  Tested manually and with fastdebug and debug.  Also removed hsfind() because find() is the same thing and nobody's using dbx anymore (and the overload that made me add it might be long gone).
> Tested with tier1 sanity.

Thanks Lois and Thomas.

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

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

From sviswanathan at openjdk.java.net  Tue May  4 22:15:59 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 4 May 2021 22:15:59 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
Message-ID: <StezlmtCIEYPZ2zJXjGOAKIq1u_E1vPOe8swB5WXquw=.2ad209b8-c8a3-4284-99b8-1af3ed1b0429@github.com>

On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge master
>  - remove whitespace
>  - Merge master
>  - Small fix
>  - cleanup
>  - x86 short vector math optimization for Vector API

@vnkozlov @AlanBateman @rose00 Looking forward to your review and feedback.
This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator](https://openjdk.java.net/jeps/414), in preparation for when targeted.

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

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

From zgu at openjdk.java.net  Tue May  4 23:13:04 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 4 May 2021 23:13:04 GMT
Subject: RFR: 8266522: Shenandoah: Shenandoah LRB calls wrong runtime barrier
 on aarch64
Message-ID: <Husxaxmq8-iusB5dS8-0WE9zUwhoW1Z0XM8uuKW5PM0=.7ec7e170-7d78-478a-a57d-3e46e46c4367@github.com>

Shsenandoah LRB calls ShenandoahRuntime::load_reference_barrier_weak() on phantom access, which is wrong.

Should call ShenandoahRuntime::load_reference_barrier_phantom() instead.

Test:
  - [x] hotspot_gc_shenandoah on Linux aarch64

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

Commit messages:
 - v1

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

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

From xliu at openjdk.java.net  Wed May  5 06:23:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 5 May 2021 06:23:54 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v10]
In-Reply-To: <zmPx3YHn7bKE8mszIl21J0R7u2vTVQksCSxv7bTMa-A=.be0c7c76-4548-48a4-aa9b-5405f23ce76e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>
 <zmPx3YHn7bKE8mszIl21J0R7u2vTVQksCSxv7bTMa-A=.be0c7c76-4548-48a4-aa9b-5405f23ce76e@github.com>
Message-ID: <w_yxdaoUL3E8pKxiiE-EsmKYq8P2hi_HCFPQ7m5GP3s=.fa29bf93-08e5-42eb-afa3-c29ed01cc8d7@github.com>

On Tue, 4 May 2021 15:47:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I do not understand why you make the _tagset member in LogDecorations optional. Could you explain this?

The reason I change _tagset from reference to pointer because I would like tosupport tagset is NULL. 
This is a corner case.  When I inject meta-information, I don't have a appropriate tagset for the log message. 
[(null)               ]  is the result from LogDecorations with a NULL tagset. 


[24.933s][warning][(null)               ]   1983 messages dropped...
[24.943s][warning][(null)               ]   1424 messages dropped...
[24.953s][warning][(null)               ]   2067 messages dropped...
[24.964s][warning][(null)               ]   2466 messages dropped...
[24.972s][warning][(null)               ]   1635 messages dropped...


here is the relevant code snippet. 

bool AsyncLogMapIterator::do_entry(LogFileOutput* output, uintx* counter) {
  LogDecorators decorators = output->decorators();
  decorators.without(LogDecorators::tags_decorator);
  LogDecorations decorations(LogLevel::Warning, decorators);
  const int sz = 128;
  char out_of_band[sz];

  if (*counter > 0) {
    jio_snprintf(out_of_band, sz, UINTX_FORMAT_W(6) " messages dropped...", *counter);
    output->write_blocking(decorations, out_of_band);
    *counter = 0;
  }

  return true;
}

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

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

From stuefe at openjdk.java.net  Wed May  5 06:46:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 5 May 2021 06:46:54 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v10]
In-Reply-To: <w_yxdaoUL3E8pKxiiE-EsmKYq8P2hi_HCFPQ7m5GP3s=.fa29bf93-08e5-42eb-afa3-c29ed01cc8d7@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <gzNIVaMkToU5Whh_RnNsMajmsBjWu2Pj7ZeagC6Gjdo=.c40beb41-0e71-45f2-a82c-e2b92f89ac67@github.com>
 <zmPx3YHn7bKE8mszIl21J0R7u2vTVQksCSxv7bTMa-A=.be0c7c76-4548-48a4-aa9b-5405f23ce76e@github.com>
 <w_yxdaoUL3E8pKxiiE-EsmKYq8P2hi_HCFPQ7m5GP3s=.fa29bf93-08e5-42eb-afa3-c29ed01cc8d7@github.com>
Message-ID: <-viyJYkwofYBVx3UGMwzzg2DXgZYFwUv6BM6DHrDEK4=.cf163cfc-845e-43ab-af66-34fec1e70b5c@github.com>

On Wed, 5 May 2021 06:20:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

> > I do not understand why you make the _tagset member in LogDecorations optional. Could you explain this?
> 
> The reason I change _tagset from reference to pointer because I would like tosupport tagset is NULL.
> This is a corner case. When I inject meta-information, I don't have a appropriate tagset for the log message.
> [(null) ] is the result from LogDecorations with a NULL tagset.
> 
> ```
> [24.933s][warning][(null)               ]   1983 messages dropped...
> [24.943s][warning][(null)               ]   1424 messages dropped...
> [24.953s][warning][(null)               ]   2067 messages dropped...
> [24.964s][warning][(null)               ]   2466 messages dropped...
> [24.972s][warning][(null)               ]   1635 messages dropped...
> ```
> 
> here is the relevant code snippet.
> 
> ```
> bool AsyncLogMapIterator::do_entry(LogFileOutput* output, uintx* counter) {
>   LogDecorators decorators = output->decorators();
>   decorators.without(LogDecorators::tags_decorator);
>   LogDecorations decorations(LogLevel::Warning, decorators);
>   const int sz = 128;
>   char out_of_band[sz];
> 
>   if (*counter > 0) {
>     jio_snprintf(out_of_band, sz, UINTX_FORMAT_W(6) " messages dropped...", *counter);
>     output->write_blocking(decorations, out_of_band);
>     *counter = 0;
>   }
> 
>   return true;
> }
> ```

Ah, I get it. I thought LogTagSet is a bitmask... why would it not be a bitmask? Again we pay for a full array here. Plus an arbitrary limitation to 5 tags.

Well, I may not know the full story.

I see what you mean and this makes sense, but I would prefer to modify tagset to allow it to be empty and have zero tags. Modifying LogDecorations to deal with something which should be done in LogTagSet just perpetuates the complexity.

Alternatively, you could just add a placeholder tag for "this set has no tags" and we leave the LogTagSet improvement for later.

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

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

From thartmann at openjdk.java.net  Wed May  5 07:28:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 5 May 2021 07:28:05 GMT
Subject: RFR: 8266542: Remove broken -XX:-UseLoopSafepoints flag
Message-ID: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>

Simply running `java -XX:-UseLoopSafepoints` already asserts and more sophisticated testing triggers all kinds of asserts and crashes in various places. [JDK-6232281](https://bugs.openjdk.java.net/browse/JDK-6232281) made an attempt of fixing a common case. I had a quick look on what it would take to fix all cases and it's definitely non trivial. Also, we would need to make sure that new optimizations work without safepoints in loops. I don't see much value in keeping the flag for debugging either because disabling safepoints in loops has massive side-effects on other optimizations.

I therefore propose to remove the flag.

Thanks,
Tobias

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

Commit messages:
 - Forgot to remove }
 - 8266542: Remove broken -XX:-UseLoopSafepoints flag

Changes: https://git.openjdk.java.net/jdk/pull/3871/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3871&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266542
  Stats: 57 lines in 5 files changed: 1 ins; 47 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3871.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3871/head:pull/3871

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

From sspitsyn at openjdk.java.net  Wed May  5 07:33:53 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 07:33:53 GMT
Subject: RFR: 8262002:
 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with
 "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2]
In-Reply-To: <goeRv9fMoeRUinXIn0aJomK4cebLlbVVlrzCCArDc7o=.f27926be-8feb-458b-8734-ef6ebfeb824c@github.com>
References: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
 <goeRv9fMoeRUinXIn0aJomK4cebLlbVVlrzCCArDc7o=.f27926be-8feb-458b-8734-ef6ebfeb824c@github.com>
Message-ID: <izu87qSKPSVsr2iZziU_It6Vi6ujHl4hMOkhKO4ALpU=.9b899b50-4051-454f-af78-6e8ef80d44a7@github.com>

On Wed, 21 Apr 2021 20:51:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution)
>> The fix:
>> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does
>> - makes the test java instead of shell
>> - added workaround for JDK-8264667
>> - test code is ready to ignore order of attributes
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the fix accordingly feedback

Hi Alex,
Looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From thartmann at openjdk.java.net  Wed May  5 07:39:54 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 5 May 2021 07:39:54 GMT
Subject: RFR: 8266504: Remove leftovers from BarrierSetAssemblerC1
In-Reply-To: <DuVkQA0ZSqj83cpRrJqlvnYk1hwk8z-EAlwWbFdiOnc=.ba5d3b1b-d371-4a96-a61b-edf4af0fd242@github.com>
References: <DuVkQA0ZSqj83cpRrJqlvnYk1hwk8z-EAlwWbFdiOnc=.ba5d3b1b-d371-4a96-a61b-edf4af0fd242@github.com>
Message-ID: <RNe8nQj362FXzSpOjF9F1z2U8uqExjUw0vqaqGdjOs4=.d800230c-a166-4a4b-a1ce-9d8861889159@github.com>

On Tue, 4 May 2021 15:19:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Earlier incarnation of Shenandoah required resolve() and naming of runtime calls. We can safely remove a bunch of obsolete code from BarrierSetC1.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1
>  - [x] tier2

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 08:55:59 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 08:55:59 GMT
Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste
 since it is never set [v3]
In-Reply-To: <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
References: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
 <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
Message-ID: <ahfXJzRGF9eSPn35pXxNDi1nVUvi74_WzXgiv_grhnI=.b70f9ec7-8444-4d1f-8b92-d3dfc79f54b0@github.com>

On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Hi Albert,
It looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From rkennke at openjdk.java.net  Wed May  5 09:43:01 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 5 May 2021 09:43:01 GMT
Subject: RFR: 8266522: Shenandoah: Shenandoah LRB calls wrong runtime
 barrier on aarch64
In-Reply-To: <Husxaxmq8-iusB5dS8-0WE9zUwhoW1Z0XM8uuKW5PM0=.7ec7e170-7d78-478a-a57d-3e46e46c4367@github.com>
References: <Husxaxmq8-iusB5dS8-0WE9zUwhoW1Z0XM8uuKW5PM0=.7ec7e170-7d78-478a-a57d-3e46e46c4367@github.com>
Message-ID: <gP7cdXZIhiPhEo3P7s_sW5MSDTPaM0ETLiwHZURzZMI=.520df569-9993-42f7-8014-d97503bb2a5e@github.com>

On Tue, 4 May 2021 19:09:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shsenandoah LRB calls ShenandoahRuntime::load_reference_barrier_weak() on phantom access, which is wrong.
> 
> Should call ShenandoahRuntime::load_reference_barrier_phantom() instead.
> 
> Test:
>   - [x] hotspot_gc_shenandoah on Linux aarch64

Looks good! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

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

From sjohanss at openjdk.java.net  Wed May  5 10:44:04 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 5 May 2021 10:44:04 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v30]
In-Reply-To: <cTF3ZRcXn5UuSr94DWj6a0VbUTOm3ogL5FwkzVer1FE=.78067f88-a9d5-4a57-bf79-4e92cfea4c5d@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <g9JpfS7APOwOQp2lVSVVQN9qgvZuq8ZEByVCwbKgPuo=.8d92f58c-38eb-4dff-8078-b45a7fbe30ab@github.com>
 <WY8gehBxfTA2BNvdp6CbdU8AiFPp5_VtySLfpr0KwsA=.8038b318-3785-4f1c-86f2-c0aa0d380e01@github.com>
 <cTF3ZRcXn5UuSr94DWj6a0VbUTOm3ogL5FwkzVer1FE=.78067f88-a9d5-4a57-bf79-4e92cfea4c5d@github.com>
Message-ID: <GHq2YMFu4kNJfKwRgUIv-1B_GVCk8vLCashe8NXeZvA=.161a85df-1c73-44b5-be83-92f5af59beab@github.com>

On Tue, 4 May 2021 17:57:27 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> > Filed [JDK-8266349](https://bugs.openjdk.java.net/browse/JDK-8266349) for passing page size down to `reserve_memory_special`. As I mentioned [here](https://github.com/openjdk/jdk/pull/1153/files#r623353767), if we do this change before this one. We should not have to care about anything but adding the available and configure page sizes to `os::_page_sizes`.
> 
> Thanks @kstefanj. Sounds like a clean way to go. Looking forward to seeing the code. Is this likely for JDK17 branch?

Yes, very likely. Just opened the PR :)

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

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

From sjohanss at openjdk.java.net  Wed May  5 10:44:20 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 5 May 2021 10:44:20 GMT
Subject: RFR: 8266349: Pass down requested page size to reserve_memory_special
Message-ID: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>

Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.

**Summary**
After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 

**Testing**
Local testing together with parts of PR #1153. Mach5 tier 1-3

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

Commit messages:
 - 8266349: Pass down requested page size to reserve_memory_special

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

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

From rkennke at openjdk.java.net  Wed May  5 10:44:58 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 5 May 2021 10:44:58 GMT
Subject: Integrated: 8266491: Remove resolve and obj_equals leftovers from
 BarrierSetAssembler
In-Reply-To: <lpcgFj_fzbl12jHFQ_mhy-1sCEQPBLIqdl4kSB-nPIw=.d3b3702d-ae75-40be-9c8b-9ef42e0ae760@github.com>
References: <lpcgFj_fzbl12jHFQ_mhy-1sCEQPBLIqdl4kSB-nPIw=.d3b3702d-ae75-40be-9c8b-9ef42e0ae760@github.com>
Message-ID: <QEZ-bloLFX92SCAgXj5o1DXJ8lUA1uyDqdI6fCNbJcc=.5e388d5a-9191-4cd4-b0f8-89a491e85947@github.com>

On Tue, 4 May 2021 11:01:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Shenandoah used to require resolve() and obj_equals() in its first incarnation in JDK12. This is long obsolete, and the corresponding code can be removed from BarrierSetAssembler. It also makes the code less confusing because obj_equals() and resolve() have both been rather clunky and given that they now do nothing (and there are other resolve* methods in BSA too), it's not even clear what they would be supposed to do. It also makes life easier for porters to other platforms.
> 
> Testing:
>  - [x] Build x86_64, x86_32
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1, tier2
>  - [x] Build arm, aarch64 (by GH-actions)

This pull request has now been integrated.

Changeset: 65ce4d20
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65ce4d20565b7152bc6c5ea18813ec62e638f7c6
Stats:     168 lines in 25 files changed: 0 ins; 161 del; 7 mod

8266491: Remove resolve and obj_equals leftovers from BarrierSetAssembler

Reviewed-by: tschatzl

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

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

From tschatzl at openjdk.java.net  Wed May  5 11:04:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 5 May 2021 11:04:55 GMT
Subject: RFR: 8266542: Remove broken -XX:-UseLoopSafepoints flag
In-Reply-To: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
References: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
Message-ID: <r342jBF6L1YT3f_V0HcuaOXf8gHOC5Fp7MdjiXJc8tM=.2beb9ea8-b38d-4380-b1e5-4ade991ef386@github.com>

On Wed, 5 May 2021 07:20:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Simply running `java -XX:-UseLoopSafepoints` already asserts and more sophisticated testing triggers all kinds of asserts and crashes in various places. [JDK-6232281](https://bugs.openjdk.java.net/browse/JDK-6232281) made an attempt of fixing a common case. I had a quick look on what it would take to fix all cases and it's definitely non trivial. Also, we would need to make sure that new optimizations work without safepoints in loops. I don't see much value in keeping the flag for debugging either because disabling safepoints in loops has massive side-effects on other optimizations.
> 
> I therefore propose to remove the flag.
> 
> Thanks,
> Tobias

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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

From shade at openjdk.java.net  Wed May  5 12:00:21 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 May 2021 12:00:21 GMT
Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v5]
In-Reply-To: <H3q38z9VoTF3idtqqPQZCVdgdCjnWN6UaeTeQVlwaFo=.aa641971-3b15-40f1-92a9-3a215653a45a@github.com>
References: <H3q38z9VoTF3idtqqPQZCVdgdCjnWN6UaeTeQVlwaFo=.aa641971-3b15-40f1-92a9-3a215653a45a@github.com>
Message-ID: <mOplLZWzKB9I31HOJjf6GQlyYWo7yUBs_mLg3Xrunag=.3c73658e-9149-4bc8-a176-a29a14abbf46@github.com>

> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions.
> 
> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. 
> 
> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans.
> 
> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing.
> 
> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'master' into JDK-8259316-blackholes-redo
 - Remove @build in favor of @library
 - Update copyrights where needed
 - Add vm.flagless requirement to tests
 - Stray whitespace
 - Merge branch 'master' into JDK-8259316-blackholes-redo
 - Merge branch 'master' into JDK-8259316-blackholes-redo
 - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified
 - Rename BlackholeStaticTest to BlackholeIntrinsicTest
 - BlackholeStaticTest should unlock blackholes
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/65ce4d20...65e865aa

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

Changes: https://git.openjdk.java.net/jdk/pull/2024/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2024&range=04
  Stats: 1167 lines in 32 files changed: 1161 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2024.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2024/head:pull/2024

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

From zgu at openjdk.java.net  Wed May  5 12:17:51 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 5 May 2021 12:17:51 GMT
Subject: Integrated: 8266522: Shenandoah: Shenandoah LRB calls wrong runtime
 barrier on aarch64
In-Reply-To: <Husxaxmq8-iusB5dS8-0WE9zUwhoW1Z0XM8uuKW5PM0=.7ec7e170-7d78-478a-a57d-3e46e46c4367@github.com>
References: <Husxaxmq8-iusB5dS8-0WE9zUwhoW1Z0XM8uuKW5PM0=.7ec7e170-7d78-478a-a57d-3e46e46c4367@github.com>
Message-ID: <yvSNm1BPXKm6vknMRJGA6M_r0Ing5hKoSMQ3fHg6H8Y=.92f23827-f464-4858-adfa-0703747e324e@github.com>

On Tue, 4 May 2021 19:09:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shsenandoah LRB calls ShenandoahRuntime::load_reference_barrier_weak() on phantom access, which is wrong.
> 
> Should call ShenandoahRuntime::load_reference_barrier_phantom() instead.
> 
> Test:
>   - [x] hotspot_gc_shenandoah on Linux aarch64

This pull request has now been integrated.

Changeset: 71d0858b
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71d0858b3216e6996e217707678680c602b4404d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8266522: Shenandoah: Shenandoah LRB calls wrong runtime barrier on aarch64

Reviewed-by: rkennke

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

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

From stuefe at openjdk.java.net  Wed May  5 12:36:51 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 5 May 2021 12:36:51 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <St6t29djIzqYR8tv9tRlU2IEYjtRN8e1FY7TrleJCzM=.9f94b56f-3590-4ff2-b285-a14ebb1a10b4@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
 <St6t29djIzqYR8tv9tRlU2IEYjtRN8e1FY7TrleJCzM=.9f94b56f-3590-4ff2-b285-a14ebb1a10b4@github.com>
Message-ID: <qP3360tdnZlMh8UxB_uIqTyjWj9R5E__k7AbDnIxMJo=.c3993d08-654f-4b4a-9f5c-730189c49301@github.com>

On Wed, 5 May 2021 12:13:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
>> 
>> **Summary**
>> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
>> 
>> **Testing**
>> Local testing together with parts of PR #1153. Mach5 tier 1-3
>
> src/hotspot/os/linux/os_linux.cpp line 3968:
> 
>> 3966:   assert(is_aligned(alignment, os::vm_allocation_granularity()), "Must be");
>> 3967:   assert(is_power_of_2(page_size), "Must be");
>> 3968:   assert(bytes >= page_size, "Shouldn't allocate large pages for small sizes");
> 
> We could replace these two asserts with _page_sizes.contains.

.. Well, the first one at least.

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

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

From stuefe at openjdk.java.net  Wed May  5 12:36:51 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 5 May 2021 12:36:51 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
Message-ID: <St6t29djIzqYR8tv9tRlU2IEYjtRN8e1FY7TrleJCzM=.9f94b56f-3590-4ff2-b285-a14ebb1a10b4@github.com>

On Wed, 5 May 2021 10:29:32 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
> 
> **Summary**
> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
> 
> **Testing**
> Local testing together with parts of PR #1153. Mach5 tier 1-3

Very good. 

This is not only cosmetic but functional, no? Since before we would always os::large_page_size(); now, in the case of ReservedSpace::ReservedSpace(size), we use whatever os::page_size_for_region wants us to use. Lets see if any errors creep up.

..Thomas

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

> 3966:   assert(is_aligned(alignment, os::vm_allocation_granularity()), "Must be");
> 3967:   assert(is_power_of_2(page_size), "Must be");
> 3968:   assert(bytes >= page_size, "Shouldn't allocate large pages for small sizes");

We could replace these two asserts with _page_sizes.contains.

src/hotspot/share/memory/virtualspace.cpp line 172:

> 170: 
> 171: static char* reserve_memory_special(char* requested_address, const size_t size,
> 172:                                     const size_t alignment, const size_t page_size, bool exec) {

I don't think the const makes sense... nor for the other arguments (but when in Rome...)

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

Marked as reviewed by stuefe (Reviewer).

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

From thartmann at openjdk.java.net  Wed May  5 12:39:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 5 May 2021 12:39:56 GMT
Subject: RFR: 8266542: Remove broken -XX:-UseLoopSafepoints flag
In-Reply-To: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
References: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
Message-ID: <H3nZ2UlwQtSpZG0igfENniJc8CFip0M3ZcA_4xAtcj8=.41cd347e-a64e-4abf-bb62-d588fed8822b@github.com>

On Wed, 5 May 2021 07:20:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Simply running `java -XX:-UseLoopSafepoints` already asserts and more sophisticated testing triggers all kinds of asserts and crashes in various places. [JDK-6232281](https://bugs.openjdk.java.net/browse/JDK-6232281) made an attempt of fixing a common case. I had a quick look on what it would take to fix all cases and it's definitely non trivial. Also, we would need to make sure that new optimizations work without safepoints in loops. I don't see much value in keeping the flag for debugging either because disabling safepoints in loops has massive side-effects on other optimizations.
> 
> I therefore propose to remove the flag.
> 
> Thanks,
> Tobias

Thanks for the review, Thomas!

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

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

From coleenp at openjdk.java.net  Wed May  5 12:47:51 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 5 May 2021 12:47:51 GMT
Subject: Integrated: 8266498: Make debug ps() call print_stack
In-Reply-To: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
References: <S6c-vYe-pr0VYp6dmNrlSxhlmLDwXQeL1a52FMcuW-s=.57d0cb61-fdf5-467b-92d7-4c2d720c5cec@github.com>
Message-ID: <aojaOMKXhcAkQnddW_hEXyYlH7V5hjyMG6a2VBf0Xnc=.d0db1593-0985-4518-90ca-931862abca84@github.com>

On Tue, 4 May 2021 16:02:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix ps() call print_stack.  Tested manually and with fastdebug and debug.  Also removed hsfind() because find() is the same thing and nobody's using dbx anymore (and the overload that made me add it might be long gone).
> Tested with tier1 sanity.

This pull request has now been integrated.

Changeset: 6ba911d6
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6ba911d64ea05a6507bcf88a8ca656088a30ba5a
Stats:     15 lines in 1 file changed: 0 ins; 12 del; 3 mod

8266498: Make debug ps() call print_stack

Reviewed-by: stuefe, lfoltan

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

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

From sjohanss at openjdk.java.net  Wed May  5 12:57:51 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 5 May 2021 12:57:51 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
Message-ID: <5sIUtZvkc2XlQl_-ad53K_8xw_emJw3U8EmX_8Ygwb4=.d2b83a5b-220a-47cf-8c16-7f95ccb710ef@github.com>

On Wed, 5 May 2021 10:29:32 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
> 
> **Summary**
> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
> 
> **Testing**
> Local testing together with parts of PR #1153. Mach5 tier 1-3

> Very good.
> 

Thanks =)

> This is not only cosmetic but functional, no? Since before we would always os::large_page_size(); now, in the case of ReservedSpace::ReservedSpace(size), we use whatever os::page_size_for_region wants us to use. Lets see if any errors creep up.
> 

I think this should not change functionality. Before I started my refactoring we did not have `ReservedSpace::ReservedSpace(size)` but this function below where the second parameter was optional. As you can see, if no `preferred_page_size` was given we would use `os::page_size_for_region_unaligned(size, 1)` which is what now is done in `ReservedSpace::ReservedSpace(size)`:

ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size) : _fd_for_heap(-1) {
  bool has_preferred_page_size = preferred_page_size != 0;
  // Want to use large pages where possible and pad with small pages.
  size_t page_size = has_preferred_page_size ? preferred_page_size : os::page_size_for_region_unaligned(size, 1);
  bool large_pages = page_size != (size_t)os::vm_page_size();
  ...


And if we end up with a page size that isn't large we will never get down into `reserve_memory_special(...)`. Does this sound correct, or did I miss your point?

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

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

From sjohanss at openjdk.java.net  Wed May  5 12:57:52 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 5 May 2021 12:57:52 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <qP3360tdnZlMh8UxB_uIqTyjWj9R5E__k7AbDnIxMJo=.c3993d08-654f-4b4a-9f5c-730189c49301@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
 <St6t29djIzqYR8tv9tRlU2IEYjtRN8e1FY7TrleJCzM=.9f94b56f-3590-4ff2-b285-a14ebb1a10b4@github.com>
 <qP3360tdnZlMh8UxB_uIqTyjWj9R5E__k7AbDnIxMJo=.c3993d08-654f-4b4a-9f5c-730189c49301@github.com>
Message-ID: <-MBWyHHxUHQJfcQphN2i0jRM9mVz0CaLs1X8RmNfCS8=.b193ae4f-0641-4934-abb1-81462f941ce0@github.com>

On Wed, 5 May 2021 12:33:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 3968:
>> 
>>> 3966:   assert(is_aligned(alignment, os::vm_allocation_granularity()), "Must be");
>>> 3967:   assert(is_power_of_2(page_size), "Must be");
>>> 3968:   assert(bytes >= page_size, "Shouldn't allocate large pages for small sizes");
>> 
>> We could replace these two asserts with _page_sizes.contains.
>
> .. Well, the first one at least.

Was just about to say just that :) The second one should trigger on the case you mention, if we ever tried to use large pages for too small sizes.

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

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

From sjohanss at openjdk.java.net  Wed May  5 12:57:53 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 5 May 2021 12:57:53 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <St6t29djIzqYR8tv9tRlU2IEYjtRN8e1FY7TrleJCzM=.9f94b56f-3590-4ff2-b285-a14ebb1a10b4@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
 <St6t29djIzqYR8tv9tRlU2IEYjtRN8e1FY7TrleJCzM=.9f94b56f-3590-4ff2-b285-a14ebb1a10b4@github.com>
Message-ID: <aG9mA9Ngqz8uOdJuMGl8lnhiVq_RPaBLzDiKzIwnkvI=.262c4f39-8559-467a-8b36-edb9da94eae1@github.com>

On Wed, 5 May 2021 12:16:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
>> 
>> **Summary**
>> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
>> 
>> **Testing**
>> Local testing together with parts of PR #1153. Mach5 tier 1-3
>
> src/hotspot/share/memory/virtualspace.cpp line 172:
> 
>> 170: 
>> 171: static char* reserve_memory_special(char* requested_address, const size_t size,
>> 172:                                     const size_t alignment, const size_t page_size, bool exec) {
> 
> I don't think the const makes sense... nor for the other arguments (but when in Rome...)

Yes, I'm staying in Rome :) But we could certainly clean it up later.

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

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

From stuefe at openjdk.java.net  Wed May  5 13:53:52 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 5 May 2021 13:53:52 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <5sIUtZvkc2XlQl_-ad53K_8xw_emJw3U8EmX_8Ygwb4=.d2b83a5b-220a-47cf-8c16-7f95ccb710ef@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
 <5sIUtZvkc2XlQl_-ad53K_8xw_emJw3U8EmX_8Ygwb4=.d2b83a5b-220a-47cf-8c16-7f95ccb710ef@github.com>
Message-ID: <yqVVYqJl52AlJ_GMVtrUC7IAglnu3TaATvkKeqPWzVM=.ad6a5d74-8e5c-44c2-a65b-730e1d094edf@github.com>

On Wed, 5 May 2021 12:55:08 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > Very good.
> 
> Thanks =)
> 
> > This is not only cosmetic but functional, no? Since before we would always os::large_page_size(); now, in the case of ReservedSpace::ReservedSpace(size), we use whatever os::page_size_for_region wants us to use. Lets see if any errors creep up.
> 
> I think this should not change functionality. Before I started my refactoring we did not have `ReservedSpace::ReservedSpace(size)` but this function below where the second parameter was optional. As you can see, if no `preferred_page_size` was given we would use `os::page_size_for_region_unaligned(size, 1)` which is what now is done in `ReservedSpace::ReservedSpace(size)`:
> 
> ```
> ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size) : _fd_for_heap(-1) {
>   bool has_preferred_page_size = preferred_page_size != 0;
>   // Want to use large pages where possible and pad with small pages.
>   size_t page_size = has_preferred_page_size ? preferred_page_size : os::page_size_for_region_unaligned(size, 1);
>   bool large_pages = page_size != (size_t)os::vm_page_size();
>   ...
> ```
> 
> And if we end up with a page size that isn't large we will never get down into `reserve_memory_special(...)`. Does this sound correct, or did I miss your point?

No, this sounds right.

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

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

From shade at openjdk.java.net  Wed May  5 14:30:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 May 2021 14:30:57 GMT
Subject: Integrated: 8259316: [REDO] C1/C2 compiler support for blackholes
In-Reply-To: <H3q38z9VoTF3idtqqPQZCVdgdCjnWN6UaeTeQVlwaFo=.aa641971-3b15-40f1-92a9-3a215653a45a@github.com>
References: <H3q38z9VoTF3idtqqPQZCVdgdCjnWN6UaeTeQVlwaFo=.aa641971-3b15-40f1-92a9-3a215653a45a@github.com>
Message-ID: <wtQOH55CAZg0mfJUGTAyXD2nRhioWUKf7E_c-nyBmwE=.3ef7991a-7f77-4441-a56d-21cc8d0d6892@github.com>

On Mon, 11 Jan 2021 10:18:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions.
> 
> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. 
> 
> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans.
> 
> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing.
> 
> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals.

This pull request has now been integrated.

Changeset: 6018336f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6018336fc5e93675482b92df76594712c238adda
Stats:     1167 lines in 32 files changed: 1161 ins; 0 del; 6 mod

8259316: [REDO] C1/C2 compiler support for blackholes

Reviewed-by: vlivanov, kvn, iignatyev

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

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

From kvn at openjdk.java.net  Wed May  5 15:54:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 5 May 2021 15:54:50 GMT
Subject: RFR: 8266542: Remove broken -XX:-UseLoopSafepoints flag
In-Reply-To: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
References: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
Message-ID: <lRsCOqXaFIRI8CYUG09Srkgv2JwweBtmBOW_MMg5-gY=.091c7246-e3eb-45ca-b1b3-0af50e86b802@github.com>

On Wed, 5 May 2021 07:20:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Simply running `java -XX:-UseLoopSafepoints` already asserts and more sophisticated testing triggers all kinds of asserts and crashes in various places. [JDK-6232281](https://bugs.openjdk.java.net/browse/JDK-6232281) made an attempt of fixing a common case. I had a quick look on what it would take to fix all cases and it's definitely non trivial. Also, we would need to make sure that new optimizations work without safepoints in loops. I don't see much value in keeping the flag for debugging either because disabling safepoints in loops has massive side-effects on other optimizations.
> 
> I therefore propose to remove the flag.
> 
> Thanks,
> Tobias

Note, `UseLoopSafepoints` is debug flag so we don't need CSR for removing it.

Consider removing `OptoRemoveUseless` debug flag too because it is related to safepoints and we never used it AFAIK:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2291

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

Marked as reviewed by kvn (Reviewer).

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

From yyang at openjdk.java.net  Wed May  5 16:23:58 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 5 May 2021 16:23:58 GMT
Subject: RFR: 8266542: Remove broken -XX:-UseLoopSafepoints flag
In-Reply-To: <lRsCOqXaFIRI8CYUG09Srkgv2JwweBtmBOW_MMg5-gY=.091c7246-e3eb-45ca-b1b3-0af50e86b802@github.com>
References: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
 <lRsCOqXaFIRI8CYUG09Srkgv2JwweBtmBOW_MMg5-gY=.091c7246-e3eb-45ca-b1b3-0af50e86b802@github.com>
Message-ID: <YG-Z8htWbm-lIZQvrnuS665z1wpX3sGNnXb6DpNcAb0=.8ee1546c-6502-44d6-adf2-b9f00b766afd@github.com>

On Wed, 5 May 2021 15:51:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Consider removing OptoRemoveUseless debug flag too because it is related to safepoints and we never used it AFAIK:

Agree!
FYI: C2 crashes in many places if turned off OptoRemoveUseless, it would takes a lot of time to fix this.

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

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

From never at openjdk.java.net  Wed May  5 16:33:57 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Wed, 5 May 2021 16:33:57 GMT
Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v5]
In-Reply-To: <mOplLZWzKB9I31HOJjf6GQlyYWo7yUBs_mLg3Xrunag=.3c73658e-9149-4bc8-a176-a29a14abbf46@github.com>
References: <H3q38z9VoTF3idtqqPQZCVdgdCjnWN6UaeTeQVlwaFo=.aa641971-3b15-40f1-92a9-3a215653a45a@github.com>
 <mOplLZWzKB9I31HOJjf6GQlyYWo7yUBs_mLg3Xrunag=.3c73658e-9149-4bc8-a176-a29a14abbf46@github.com>
Message-ID: <nlG_nF6114X9kdWRonTCsysoB9HkfDQ39Gv-Vpi2594=.148e9955-4cdf-46a5-ba2b-7f8e153611e2@github.com>

On Wed, 5 May 2021 12:00:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions.
>> 
>> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. 
>> 
>> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans.
>> 
>> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing.
>> 
>> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge branch 'master' into JDK-8259316-blackholes-redo
>  - Remove @build in favor of @library
>  - Update copyrights where needed
>  - Add vm.flagless requirement to tests
>  - Stray whitespace
>  - Merge branch 'master' into JDK-8259316-blackholes-redo
>  - Merge branch 'master' into JDK-8259316-blackholes-redo
>  - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified
>  - Rename BlackholeStaticTest to BlackholeIntrinsicTest
>  - BlackholeStaticTest should unlock blackholes
>  - ... and 17 more: https://git.openjdk.java.net/jdk/compare/65ce4d20...65e865aa

Due to my misunderstanding the github review process I had a pending comment here which was never posted.   In this code, https://github.com/openjdk/jdk/commit/6018336fc5e93675482b92df76594712c238adda#diff-fa2433a762244542fec57f9d58dd3092bae74f354acf0ef33603a5f8306fd7daR995, the call to CompilerOracle::tag_blackhole_if_possible should be outside of the if.  As written, methods won't be properly tagged for libgraal, only when used with the pure Java graal.

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

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

From github.com+168222+mgkwill at openjdk.java.net  Wed May  5 16:45:55 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 5 May 2021 16:45:55 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
Message-ID: <Xg4XZrxvLIgw2QPKPU-rwAHD8EiI1jzBV9U8Qm6LMdg=.3a81c9f6-7067-46c1-b48c-b88d8c326ac1@github.com>

On Wed, 5 May 2021 10:29:32 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
> 
> **Summary**
> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
> 
> **Testing**
> Local testing together with parts of PR #1153. Mach5 tier 1-3

??

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

Marked as reviewed by mgkwill at github.com (no known OpenJDK username).

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

From shade at openjdk.java.net  Wed May  5 16:47:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 May 2021 16:47:53 GMT
Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v5]
In-Reply-To: <nlG_nF6114X9kdWRonTCsysoB9HkfDQ39Gv-Vpi2594=.148e9955-4cdf-46a5-ba2b-7f8e153611e2@github.com>
References: <H3q38z9VoTF3idtqqPQZCVdgdCjnWN6UaeTeQVlwaFo=.aa641971-3b15-40f1-92a9-3a215653a45a@github.com>
 <mOplLZWzKB9I31HOJjf6GQlyYWo7yUBs_mLg3Xrunag=.3c73658e-9149-4bc8-a176-a29a14abbf46@github.com>
 <nlG_nF6114X9kdWRonTCsysoB9HkfDQ39Gv-Vpi2594=.148e9955-4cdf-46a5-ba2b-7f8e153611e2@github.com>
Message-ID: <IGCle5uHl7wBcgfnHpEHqOTodWv4gjSERS5jxCBkPV4=.1e4e563a-a584-4719-963f-ca2e2e1f5729@github.com>

On Wed, 5 May 2021 16:30:47 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> the call to CompilerOracle::tag_blackhole_if_possible should be outside of the if. 

Oh. See the follow-up in #3887.

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

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

From github.com+168222+mgkwill at openjdk.java.net  Wed May  5 17:51:25 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 5 May 2021 17:51:25 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v31]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <MHqbs77S09Zx7IjNoEyi9xjQ1BgpDTroLPyhJwUzbDs=.1b9b1ac1-4e14-4c18-925e-889983d269ce@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Remove extranous vm_page_size check
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1153/files
  - new: https://git.openjdk.java.net/jdk/pull/1153/files/6cd6be15..a2495c49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=30
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=29-30

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

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

From sviswanathan at openjdk.java.net  Wed May  5 18:05:50 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 5 May 2021 18:05:50 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms
In-Reply-To: <T7UeoXMOY_d-MYcrRKOHXc0P7FaBWwFVErWu59ztCVA=.837926a5-4762-408c-a154-68652867aa5b@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <T7UeoXMOY_d-MYcrRKOHXc0P7FaBWwFVErWu59ztCVA=.837926a5-4762-408c-a154-68652867aa5b@github.com>
Message-ID: <bnp9eZKLnkxUZR6TNbciIFkMylR8Md25BsEwOtla6jI=.e4c0f5a6-7f0a-42b5-81a2-a904c419bdac@github.com>

On Thu, 29 Apr 2021 23:53:58 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Currently, only 64-bit Linux is supported

@xbzhang99 The patch looks good to me now. Thanks for making all the changes.

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

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

From rkennke at openjdk.java.net  Wed May  5 19:20:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 5 May 2021 19:20:53 GMT
Subject: Integrated: 8266504: Remove leftovers from BarrierSetAssemblerC1
In-Reply-To: <DuVkQA0ZSqj83cpRrJqlvnYk1hwk8z-EAlwWbFdiOnc=.ba5d3b1b-d371-4a96-a61b-edf4af0fd242@github.com>
References: <DuVkQA0ZSqj83cpRrJqlvnYk1hwk8z-EAlwWbFdiOnc=.ba5d3b1b-d371-4a96-a61b-edf4af0fd242@github.com>
Message-ID: <YoXo-ZSELjH5FD_umn3yGchToFqMk0bEiyPXf-uj8gA=.93549aef-fc28-4f4b-b9c7-159360de36fe@github.com>

On Tue, 4 May 2021 15:19:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Earlier incarnation of Shenandoah required resolve() and naming of runtime calls. We can safely remove a bunch of obsolete code from BarrierSetC1.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1
>  - [x] tier2

This pull request has now been integrated.

Changeset: 1885c83a
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1885c83aca4f7bae43c5dfb9de185a4253d9fe2b
Stats:     42 lines in 7 files changed: 0 ins; 38 del; 4 mod

8266504: Remove leftovers from BarrierSetAssemblerC1

Reviewed-by: thartmann

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

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

From xliu at openjdk.java.net  Wed May  5 22:17:17 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 5 May 2021 22:17:17 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

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

  Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/98ae33fb..1d5e5407

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

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

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

From dongbo at openjdk.java.net  Thu May  6 01:51:51 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 6 May 2021 01:51:51 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
Message-ID: <qRsJulDw5vO46wRN5uFFCU4KYw_I92qCK6X8klWJdkg=.14bc9564-cf9a-4f3f-91ef-68f8b7f43a8a@github.com>

On Mon, 26 Apr 2021 11:16:00 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
>> 
>> 
>> ## reduce_add2I, before
>> mov    w10, v19.s[0]
>> mov    w2, v19.s[1]
>> add    w10, w0, w10
>> add    w10, w10, w2
>> ## reduce_add2I, optimized
>> addp   v23.2s, v24.2s, v24.2s
>> mov    w10, v23.s[0]
>> add    w10, w10, w2
>> 
>> ## reduce_max2I, before
>> dup    v16.2d, v23.d[0]
>> sminv  s16, v16.4s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> ## reduce_max2I, optimized
>> sminp  v16.2s, v23.2s, v23.2s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> 
>> 
>> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
>> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
>> 
>> 
>> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
>> # optimized
>> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
>> # default
>> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
>> 
>> 
>> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
>> 
>> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assembler tests for smaxp/sminp

Hi, @theRealAph. Could you please take a look at this PR? Thanks.

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

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

From ysuenaga at openjdk.java.net  Thu May  6 06:59:51 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 6 May 2021 06:59:51 GMT
Subject: RFR: 8266172: -Wstringop-overflow happens in vmError.cpp
In-Reply-To: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
References: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
Message-ID: <qVmAg2sx2vMzEPGprUpMpN-XjBZuS-4sdECu2y46URc=.ea734206-6df7-4c11-a80c-d65cb667a2d8@github.com>

On Thu, 29 Apr 2021 07:26:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see following compiler warnings in vmError.cpp on GCC 11.
> 
> 
> In function 'void crash_with_segfault()',
>     inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33:

Ping: Could you review this PR? I need one more reviewer to push. We still see this warning with GCC 11.1.

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

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

From stuefe at openjdk.java.net  Thu May  6 07:17:53 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 6 May 2021 07:17:53 GMT
Subject: RFR: 8266172: -Wstringop-overflow happens in vmError.cpp
In-Reply-To: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
References: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
Message-ID: <Sjqlppr28FG7iF9yPlfBw8IyDkCAnVhfB1bC39zdk1w=.b10b020d-0507-4541-9aee-3daa39abdac4@github.com>

On Thu, 29 Apr 2021 07:26:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see following compiler warnings in vmError.cpp on GCC 11.
> 
> 
> In function 'void crash_with_segfault()',
>     inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33:

I'm fine with this patch. 

nit: does the C++ styleguide require C++ casts now? I don't remember seeing anything. I dislike the verbosity of these casts.

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

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

From thartmann at openjdk.java.net  Thu May  6 07:36:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 May 2021 07:36:50 GMT
Subject: RFR: 8266542: Remove broken -XX:-UseLoopSafepoints flag
In-Reply-To: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
References: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
Message-ID: <FdjBFd9ggJ9cFiriTI3Vick9SJjCQ9k3lsklwhDNA1Y=.4a45cc28-edec-4a4a-9b8f-2156d5b41703@github.com>

On Wed, 5 May 2021 07:20:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Simply running `java -XX:-UseLoopSafepoints` already asserts and more sophisticated testing triggers all kinds of asserts and crashes in various places. [JDK-6232281](https://bugs.openjdk.java.net/browse/JDK-6232281) made an attempt of fixing a common case. I had a quick look on what it would take to fix all cases and it's definitely non trivial. Also, we would need to make sure that new optimizations work without safepoints in loops. I don't see much value in keeping the flag for debugging either because disabling safepoints in loops has massive side-effects on other optimizations.
> 
> I therefore propose to remove the flag.
> 
> Thanks,
> Tobias

Thanks for the review, Vladimir! Good point, I'll remove `OptoRemoveUseless` as well with a separate PR.

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

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

From thartmann at openjdk.java.net  Thu May  6 07:39:52 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 May 2021 07:39:52 GMT
Subject: Integrated: 8266542: Remove broken -XX:-UseLoopSafepoints flag
In-Reply-To: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
References: <GoUvUwJr91OBWdZ__PsuSxE0BHexS09CqTGjNeCZAy0=.8d07d572-d00c-4b07-b140-dccc4d54402a@github.com>
Message-ID: <Q0kHA8Lawc1vsGtILHCHtXLlYo1_HqbSjAfpWXcZbzs=.533a1a54-368d-4d2b-9876-cf321c7d7fce@github.com>

On Wed, 5 May 2021 07:20:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Simply running `java -XX:-UseLoopSafepoints` already asserts and more sophisticated testing triggers all kinds of asserts and crashes in various places. [JDK-6232281](https://bugs.openjdk.java.net/browse/JDK-6232281) made an attempt of fixing a common case. I had a quick look on what it would take to fix all cases and it's definitely non trivial. Also, we would need to make sure that new optimizations work without safepoints in loops. I don't see much value in keeping the flag for debugging either because disabling safepoints in loops has massive side-effects on other optimizations.
> 
> I therefore propose to remove the flag.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 22ca62c2
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/22ca62c2cb61940dd7b1028925cd651ffdf80690
Stats:     57 lines in 5 files changed: 1 ins; 47 del; 9 mod

8266542: Remove broken -XX:-UseLoopSafepoints flag

Reviewed-by: tschatzl, kvn

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

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

From ysuenaga at openjdk.java.net  Thu May  6 07:41:52 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 6 May 2021 07:41:52 GMT
Subject: RFR: 8266172: -Wstringop-overflow happens in vmError.cpp
In-Reply-To: <Sjqlppr28FG7iF9yPlfBw8IyDkCAnVhfB1bC39zdk1w=.b10b020d-0507-4541-9aee-3daa39abdac4@github.com>
References: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
 <Sjqlppr28FG7iF9yPlfBw8IyDkCAnVhfB1bC39zdk1w=.b10b020d-0507-4541-9aee-3daa39abdac4@github.com>
Message-ID: <m3_ntbNRH6e2J05s-3W-zcDbtDgOOnEpKYQqkd5vUgI=.fb240441-a8d1-4999-b20d-463dc068ef12@github.com>

On Thu, 6 May 2021 07:14:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We can see following compiler warnings in vmError.cpp on GCC 11.
>> 
>> 
>> In function 'void crash_with_segfault()',
>>     inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33:
>
> I'm fine with this patch. 
> 
> nit: does the C++ styleguide require C++ casts now? I don't remember seeing anything. I dislike the verbosity of these casts.
> 
> Cheers, Thomas

Thanks @tstuefe for the review!

> does the C++ styleguide require C++ casts now? I don't remember seeing anything.

Me too, but I found 745 entries when I grep'ed HotSpot source with `'_cast<'`, and also HotSpot is starting to use C++ 14 since JEP 347. So I decided to use C++ casts at here.

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

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

From ngasson at openjdk.java.net  Thu May  6 10:09:09 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 6 May 2021 10:09:09 GMT
Subject: RFR: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
Message-ID: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>

LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
without the additional 2*wordSize needed to store FP/LR (i.e. just the
space required for the C1 locals).  When we pass this value to
MacroAssembler build_frame and remove_frame we need to remember to add
back the 2*wordSize.  This patch changes initial_frame_size_in_bytes()
to return the full frame size including the space for FP/LR.  The PPC
and S390 ports already do this, and it also matches the behaviour of
C->output()->frame_size_in_bytes() in C2.

This change may seem a bit trivial in mainline but the Valhalla lworld
branch makes more calls to build_frame/remove_frame in C1 and keeping
track of whether "framesize" is with or without FP/LR quickly becomes
confusing.

Tested tier1 on AArch64.  The only use of this function is as input to
C1_MacroAssembler build_frame() and remove_frame() so seems safe.

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

Commit messages:
 - 8266609: AArch64: include FP/LR space in LIR_Assembler::initial_frame_size_in_bytes()

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

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

From yyang at openjdk.java.net  Thu May  6 10:14:16 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 6 May 2021 10:14:16 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v7]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <mIrATROaCK1ycNPijuExchxXIMG0t8-4_EbUSWYPMIQ=.196d7f0e-e4b5-4dbe-841f-cc2fcfe5744e@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

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

 - cmp clobbers its left argument on x86_32
 - Merge branch 'master' into consolidate_checkindex
 - better check1-4
 - AssertionError when expected exception was not thrown
 - remove extra newline
 - remove InlineNIOCheckIndex flag
 - remove java_nio_Buffer in javaClasses.hpp
 - consolidate

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

Changes: https://git.openjdk.java.net/jdk/pull/3615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=06
  Stats: 331 lines in 11 files changed: 235 ins; 78 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

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

From aph at openjdk.java.net  Thu May  6 10:32:51 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 6 May 2021 10:32:51 GMT
Subject: RFR: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
In-Reply-To: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
References: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
Message-ID: <uf1Teb83LfitgTUnRQqcXLFvjq0GPUhSt4Zai-J93IU=.d3da50fa-6511-41e2-8c0f-806ae956b950@github.com>

On Thu, 6 May 2021 10:03:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
> without the additional 2*wordSize needed to store FP/LR (i.e. just the
> space required for the C1 locals).  When we pass this value to
> MacroAssembler build_frame and remove_frame we need to remember to add
> back the 2*wordSize.  This patch changes initial_frame_size_in_bytes()
> to return the full frame size including the space for FP/LR.  The PPC
> and S390 ports already do this, and it also matches the behaviour of
> C->output()->frame_size_in_bytes() in C2.
> 
> This change may seem a bit trivial in mainline but the Valhalla lworld
> branch makes more calls to build_frame/remove_frame in C1 and keeping
> track of whether "framesize" is with or without FP/LR quickly becomes
> confusing.
> 
> Tested tier1 on AArch64.  The only use of this function is as input to
> C1_MacroAssembler build_frame() and remove_frame() so seems safe.

This calculation is the same as x86. Can you explain why it has to be changed on AArch64, but should not be changed on x86?

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 377:

> 375:   // if rounding, must let FrameMap know!
> 376: 
> 377:   return in_bytes(frame_map()->framesize_in_bytes());

Umm, really? `framesize_in_bytes()` returns a value that has to be converted to bytes?

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

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

From yyang at openjdk.java.net  Thu May  6 11:17:18 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 6 May 2021 11:17:18 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v8]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <DQDnkcpyd0OATcu27mrOlm64Df_7v9nled-v3-i2mLY=.af4c7977-1c18-4f79-a49e-1595ecc23908@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

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

  build failed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/e4959148..f996c99f

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

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

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

From github.com+3019228+codonell at openjdk.java.net  Thu May  6 12:21:54 2021
From: github.com+3019228+codonell at openjdk.java.net (Carlos O'Donell)
Date: Thu, 6 May 2021 12:21:54 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
Message-ID: <xUHZSnsfMEbYwyS2fryrymLIVhA-Mq4FF30KZizo3x8=.04428a6c-4a83-43b5-bf30-2198076ff085@github.com>

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne at openjdk.org> wrote:

> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
> 
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux.cpp/hpp.
> This is then used to select the glibcs implementation of
> log, log10, exp at runtime for c1 and c2, iff we have
> glibc 2.29 or greater.
> 
> This will ensure OpenJDK can benefit from future improvements
> to glibc.
> 
> Glibc adheres to the ieee754 standard, unless stated otherwise
> in its spec.
> 
> As there are no stated exceptions in the current glibc spec
> for dlog, dlog10 and dexp, we can assume they currently follow
> ieee754 (which testing confirms). As such, future version of
> glibc are unlikely to lose this compliance with ieee754 in
> future.
> 
> W.r.t performance this patch sees ~15-30% performance improvements for
> log and log10, with ~50-80% performance improvements for exp for the
> common input ranged (which output real numbers). However for the NaN
> and inf output ranges we see a slow down of up to a factor of 2 for
> some functions and architectures.
> 
> Due to this being the uncommon case we assert that this is a
> worthwhile tradeoff.

Where does the requirement for monotonicity come from?

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

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

From david.holmes at oracle.com  Thu May  6 14:08:02 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 7 May 2021 00:08:02 +1000
Subject: RFR: 8266172: -Wstringop-overflow happens in vmError.cpp
In-Reply-To: <Sjqlppr28FG7iF9yPlfBw8IyDkCAnVhfB1bC39zdk1w=.b10b020d-0507-4541-9aee-3daa39abdac4@github.com>
References: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
 <Sjqlppr28FG7iF9yPlfBw8IyDkCAnVhfB1bC39zdk1w=.b10b020d-0507-4541-9aee-3daa39abdac4@github.com>
Message-ID: <bcd9a1a0-8e7e-c3f0-2204-c3adc65e51ca@oracle.com>

On 6/05/2021 5:17 pm, Thomas Stuefe wrote:
> On Thu, 29 Apr 2021 07:26:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:
> 
>> We can see following compiler warnings in vmError.cpp on GCC 11.
>>
>>
>> In function 'void crash_with_segfault()',
>>      inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33:
> 
> I'm fine with this patch.
> 
> nit: does the C++ styleguide require C++ casts now? I don't remember seeing anything. I dislike the verbosity of these casts.

The hotspot style guide says nothing about casts, but internally we've 
been switching to using C++ casts and avoid old C-style casts.

Cheers,
David

> Cheers, Thomas
> 
> -------------
> 
> Marked as reviewed by stuefe (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3789
> 

From ayang at openjdk.java.net  Thu May  6 14:08:11 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 6 May 2021 14:08:11 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
Message-ID: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>

Adding the assertion, and fixing a benign violation.

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

Commit messages:
 - delta

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

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

From mcimadamore at openjdk.java.net  Thu May  6 14:23:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 6 May 2021 14:23:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v12]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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

  Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/72eb9bbc..926229ed

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

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

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

From ddong at openjdk.java.net  Thu May  6 14:34:14 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 6 May 2021 14:34:14 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function
Message-ID: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>

JDK-8249719 has fixed the bad hash function problem, however, when there are a large number of classes with the same name, there are still performance problems.
Add the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

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

Commit messages:
 - 8266642: improve ResolvedMethodTable hash function

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

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

From zgu at openjdk.java.net  Thu May  6 14:50:07 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 6 May 2021 14:50:07 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test failed
 on AArch64
Message-ID: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>

JDK-8263427 missed corresponding changes for aarch64.

LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.

Test:

- [x] hotspot_gc_shenandoah on Macosx/AArch64
- [ ] hotspot_gc_shenandoah on Linux 64/AArch64

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

Commit messages:
 - update
 - v1

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

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

From kbarrett at openjdk.java.net  Thu May  6 15:11:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 6 May 2021 15:11:55 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <2VNBXmGCpt8UsMoUEK3erio92KDhFawnW0ynzG78T1I=.096bcc7b-7051-4452-be67-aa99947d18eb@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

src/hotspot/share/classfile/vmSymbols.hpp line 490:

> 488:   template(data_cache_line_flush_size_name,           "DATA_CACHE_LINE_FLUSH_SIZE")               \
> 489:   template(during_unsafe_access_name,                 "during_unsafe_access")                     \
> 490:   template(no_deduplication_name,                     "no_deduplication")                         \

This addition was left over from an earlier version of the change, where I'd added an ordinary private boolean member of this name to String.  That was before I learned about injected members and before the idea of adding "duplication requested" came up.  This name is no longer needed, and I'll be removing it.

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

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

From stuefe at openjdk.java.net  Thu May  6 16:10:12 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 6 May 2021 16:10:12 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
Message-ID: <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>

On Wed, 5 May 2021 22:17:17 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.

Hi Xin,

I had a first look. This is a massive change, review will take some more time. Had a look at logAsyncFlusher.hpp and the gtests. 

Cheers, Thomas

src/hotspot/share/logging/logAsyncFlusher.hpp line 37:

> 35: 
> 36: template <typename E, MEMFLAGS F>
> 37: class LinkedListDeque : private LinkedListImpl<E, ResourceObj::C_HEAP, F> {

I don't think it is good design to reuse LinkedList as a base class for this. The base class is unaware of the fact that you keep track of the list tail here. If used incorrectly (eg calling base class removal functions) you could damage this structure, because the tail node gets removed. Its also not really clear: a deque has two pointers, and here they are spread over different points in the class hierarchy.

Moreover, this is ambivalent in naming: "LinkedListDeque" suggests a general purpose class, which this is not.

Since a deque is really trivial to implement, I would suggest scrapping this class and just implement a very primitive deque custom tailored to your needs and name it AsyncLogBuffer or AsyncLogBufferDeque. It does not even have to be templatized. All it needs is push_front, pop_back, some sort of "take over" operation to move list content to another list, and the peeks. 

I also would suggest you don't add an explicit node object but just give AsyncLogMessage directly a "next" pointer and use it as its own node; that way, you can save copy constructor calls. You can then make AsyncLogMessage a non-copyable object, perhabs even immutable, just with that one constructor. And you can transform "AsyncLogMessage::destroy" to a real destructor, let the list take care of destruction, and do not need to call "destroy" explicitly on writeback.

An additional advantage of a custom deque is that we can optimize it later for our purposes without inconveniencing anyone: e.g. changing the allocation for the nodes to raw malloc to be able to use UL in the memory allocation layer, or slab-allocation of nodes....

src/hotspot/share/logging/logAsyncFlusher.hpp line 54:

> 52:   }
> 53: 
> 54:   void pop_all(LinkedList<E>* logs) {

If you do your own Deque as proposed above, I would change this to a simple "take_over" operation where you hand over _head and _tail to the new list and NULL them out in the old one. Way easier to read. You do not need the ability of "move()" to append to a non-empty receiver list.

src/hotspot/share/logging/logAsyncFlusher.hpp line 86:

> 84:   LogFileOutput&   _output;
> 85:   LogDecorations*  _decorations;
> 86:   char*            _message;

I would keep decorations by value here. They are small enough.

src/hotspot/share/logging/logAsyncFlusher.hpp line 93:

> 91:     _decorations = new LogDecorations(decorations);
> 92:       // allow to fail here, then _message is NULL
> 93:     _message = os::strdup(msg, mtLogging);

Idea for a future improvement. If we knew here that message is a string literal (many are, since many log messages don't have format specifiers) we could just store the original pointer and save the strdup.

src/hotspot/share/logging/logAsyncFlusher.hpp line 107:

> 105:   void writeback();
> 106: 
> 107:   // two AsyncLogMessage are equal if both _output and _message are same.

Decorators don't matter here?

src/hotspot/share/logging/logAsyncFlusher.hpp line 123:

> 121: 
> 122: typedef LinkedListDeque<AsyncLogMessage, mtLogging> AsyncLogBuffer;
> 123: typedef KVHashtable<LogFileOutput*, uintx, mtLogging> AsyncLogMap;

This is just to keep statistics of dropped messages per output, right? 

I think it would be a lot simpler just to add a reset-able counter to LogFileOutput directly. I don't even think it has to be uintx. 32bit should be sufficient (also, uintx makes no sense - do we somehow expect less message drops on 32bit platforms?)

test/hotspot/gtest/logging/test_asynclog.cpp line 44:

> 42: };
> 43: 
> 44: class AsyncLogTest : public LogTestFixture {

Unless you plan to add other code to this fixture I would prefer a regular RAII object like we do in hotspot, and naming it `AsyncModeMark`, and placing it at the start of each function instead. 

Reason: you can use EXPECT macros inside to test stuff and they fire as part of the test, its easier to debug, and it is common notation so hotspot devs know what this is without looking up rules about googletest fixtures.

But kudos for leaving clean state after your tests.

test/hotspot/gtest/logging/test_asynclog.cpp line 45:

> 43: 
> 44: class AsyncLogTest : public LogTestFixture {
> 45:   bool _saved_async_mode;

const?

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

Changes requested by stuefe (Reviewer).

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

From jbhateja at openjdk.java.net  Thu May  6 16:49:54 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 6 May 2021 16:49:54 GMT
Subject: RFR: 8266317: Vector API enhancements
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: <tO0WlUo3VClujaA5JYx1-P80x9JZlR80m6fzKxAqRe0=.d11519c4-b29c-46a3-b034-fd0cce20c848@github.com>

On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

Reviewed X86 backend changes for unsigned comparison.

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

Marked as reviewed by jbhateja (Committer).

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Thu May  6 17:12:37 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Thu, 6 May 2021 17:12:37 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v6]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> For the following benchmark:
> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> 
> The optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

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

  remove checking AVX_512 in vbroadcastf128

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/172d7c63..72a0d3f3

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

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

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

From sviswanathan at openjdk.java.net  Thu May  6 17:36:02 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 6 May 2021 17:36:02 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v6]
In-Reply-To: <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
Message-ID: <6qI3wSgRGjKl9kq1i-ryg4DkAo7Zl5JGlNCGsg4nsGk=.e4d141d0-42d2-4690-9555-ac07d8702029@github.com>

On Thu, 6 May 2021 17:12:37 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove checking AVX_512 in vbroadcastf128

Marked as reviewed by sviswanathan (Committer).

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

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

From amenkov at openjdk.java.net  Thu May  6 18:37:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 6 May 2021 18:37:54 GMT
Subject: Integrated: 8262002:
 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with
 "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
In-Reply-To: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
References: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
Message-ID: <y4aj29pozhT4bBqSPdesdr6flTNj0T48zRLlyv3fLWE=.a56de1fc-8f6e-4b6d-9a2f-e8e1799fbc99@github.com>

On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution)
> The fix:
> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does
> - makes the test java instead of shell
> - added workaround for JDK-8264667
> - test code is ready to ignore order of attributes

This pull request has now been integrated.

Changeset: 52f1db6b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52f1db6b6f7f5e5823ee84fc31edddf89ed21df4
Stats:     216 lines in 4 files changed: 109 ins; 97 del; 10 mod

8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"

Reviewed-by: coleenp, sspitsyn

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

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

From ngasson at openjdk.java.net  Fri May  7 01:44:57 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 7 May 2021 01:44:57 GMT
Subject: RFR: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
In-Reply-To: <uf1Teb83LfitgTUnRQqcXLFvjq0GPUhSt4Zai-J93IU=.d3da50fa-6511-41e2-8c0f-806ae956b950@github.com>
References: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
 <uf1Teb83LfitgTUnRQqcXLFvjq0GPUhSt4Zai-J93IU=.d3da50fa-6511-41e2-8c0f-806ae956b950@github.com>
Message-ID: <iet7wRxA_BkNZ4x3dJ8b4O66py6BAnC0hbyDvLNuAAQ=.3c94aa80-568a-4819-bab2-a545bae583f8@github.com>

On Thu, 6 May 2021 10:28:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
>> without the additional 2*wordSize needed to store FP/LR (i.e. just the
>> space required for the C1 locals).  When we pass this value to
>> MacroAssembler build_frame and remove_frame we need to remember to add
>> back the 2*wordSize.  This patch changes initial_frame_size_in_bytes()
>> to return the full frame size including the space for FP/LR.  The PPC
>> and S390 ports already do this, and it also matches the behaviour of
>> C->output()->frame_size_in_bytes() in C2.
>> 
>> This change may seem a bit trivial in mainline but the Valhalla lworld
>> branch makes more calls to build_frame/remove_frame in C1 and keeping
>> track of whether "framesize" is with or without FP/LR quickly becomes
>> confusing.
>> 
>> Tested tier1 on AArch64.  The only use of this function is as input to
>> C1_MacroAssembler build_frame() and remove_frame() so seems safe.
>
> src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 377:
> 
>> 375:   // if rounding, must let FrameMap know!
>> 376: 
>> 377:   return in_bytes(frame_map()->framesize_in_bytes());
> 
> Umm, really? `framesize_in_bytes()` returns a value that has to be converted to bytes?

`framesize_in_bytes()` returns a struct ByteSize that needs to be converted to an int with `in_bytes()`. The extra _in_bytes seems a bit redundant but it's not my name :-)

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

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

From ngasson at openjdk.java.net  Fri May  7 01:51:51 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 7 May 2021 01:51:51 GMT
Subject: RFR: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
In-Reply-To: <uf1Teb83LfitgTUnRQqcXLFvjq0GPUhSt4Zai-J93IU=.d3da50fa-6511-41e2-8c0f-806ae956b950@github.com>
References: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
 <uf1Teb83LfitgTUnRQqcXLFvjq0GPUhSt4Zai-J93IU=.d3da50fa-6511-41e2-8c0f-806ae956b950@github.com>
Message-ID: <XZbFU0bi7WawyxGuJUlIMOvsq2BqbyVccSBYQTnJRE4=.0a8ac8a4-096a-4ce6-a1a6-3bc0ce2f1d39@github.com>

On Thu, 6 May 2021 10:30:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This calculation is the same as x86. Can you explain why it has to be changed on AArch64, but should not be changed on x86?

On AArch64 `C1_MacroAssembler::build_frame()` delegates to `MacroAssembler::build_frame()` which expects the total frame size. On x86 we build the frame directly in C1_MacroAssembler by doing roughly `__ push(rbp); __ decrement(rsp, frame_size_in_bytes);` so it's natural that `frame_size_in_bytes` shouldn't include the space for the frame pointer and the return address (which was already pushed by the `call` instruction). If we made this change on x86 we'd need to subtract `2*wordSize` from each increment/decrement of rsp which seems like a net loss.

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

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

From ngasson at openjdk.java.net  Fri May  7 03:22:07 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 7 May 2021 03:22:07 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64
In-Reply-To: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
Message-ID: <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>

On Thu, 6 May 2021 14:40:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8263427 missed corresponding changes for aarch64.
> 
> LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Macosx/AArch64
> - [ ] hotspot_gc_shenandoah on Linux 64/AArch64

src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 249:

> 247:   } else {
> 248:     if (dst == rscratch1) {
> 249:       __ push(rscratch1, sp);

Could we avoid the push/pop by passing in an extra temporary? We have `tmp1` available in `ShenandoahBarrierSetAssembler::load_at()` which is the only place that calls this.

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

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

From ysuenaga at openjdk.java.net  Fri May  7 03:25:03 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 7 May 2021 03:25:03 GMT
Subject: Integrated: 8266172: -Wstringop-overflow happens in vmError.cpp
In-Reply-To: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
References: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com>
Message-ID: <WZgKxUBBzxRzP6DJR7DUNnmLNhEUC2d3hEa9SpFcpvM=.a0beb13b-7077-40c7-8b35-84f40dd13fe2@github.com>

On Thu, 29 Apr 2021 07:26:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see following compiler warnings in vmError.cpp on GCC 11.
> 
> 
> In function 'void crash_with_segfault()',
>     inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33:

This pull request has now been integrated.

Changeset: c97f56cd
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c97f56cdafe26dfafcfbc6bb42fa5617641c1a59
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8266172: -Wstringop-overflow happens in vmError.cpp

Reviewed-by: dholmes, stuefe

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

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

From jbhateja at openjdk.java.net  Fri May  7 05:39:55 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 7 May 2021 05:39:55 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v6]
In-Reply-To: <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
Message-ID: <JhDrIHgzw3-cDrwA66LR7UjLhU0eeUq4Sl5yMREu6Us=.e2419cde-b466-4790-81a4-0eb39b51215b@github.com>

On Thu, 6 May 2021 17:12:37 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove checking AVX_512 in vbroadcastf128

Marked as reviewed by jbhateja (Committer).

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

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

From xliu at openjdk.java.net  Fri May  7 06:13:19 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 7 May 2021 06:13:19 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

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

  Change option AsyncLogBufferEntries to AsyncLogBufferSize.
  
  AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
  User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/1d5e5407..c67d74e8

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

  Stats: 22 lines in 6 files changed: 9 ins; 3 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

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

From ddong at openjdk.java.net  Fri May  7 06:27:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 7 May 2021 06:27:25 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

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

  minor adjustment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/a552ea69..8d500a84

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

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

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

From xliu at openjdk.java.net  Fri May  7 06:31:53 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 7 May 2021 06:31:53 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
Message-ID: <7NSek1vJKe2IhUCPtObalVJqfjczfkD9KrgrTvtlROc=.523f6b98-149c-4307-ae13-bfb315b62f7f@github.com>

On Thu, 6 May 2021 16:03:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.
>
> src/hotspot/share/logging/logAsyncFlusher.hpp line 123:
> 
>> 121: 
>> 122: typedef LinkedListDeque<AsyncLogMessage, mtLogging> AsyncLogBuffer;
>> 123: typedef KVHashtable<LogFileOutput*, uintx, mtLogging> AsyncLogMap;
> 
> This is just to keep statistics of dropped messages per output, right? 
> 
> I think it would be a lot simpler just to add a reset-able counter to LogFileOutput directly. I don't even think it has to be uintx. 32bit should be sufficient (also, uintx makes no sense - do we somehow expect less message drops on 32bit platforms?)

Yes, it is for the statistics of dropped messages.

AsyncLogMap looks a little cumbersome indeed, but the good side is that I isolate async logging things in logAsyncFlusher.hpp/cpp.  I manage not to pollute shared unified logging code. 

Another reason is that I can deliver the zero-cost promise when async logging is off.  If I move the counter to LogFileOutput, it will increase those object size a little bit.  In current implementation,  the singleton object LogAsyncFlusher is not created if -Xlog:async is absent.

Size wise, I think it's okay to to have 8 byte.  if a network-based device disappeared, who know how long asynclog thread  would block.  bigger counter is better.  Cost is almost same because the number of logFileOutput objects is usually less than 4.

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

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

From stuefe at openjdk.java.net  Fri May  7 06:58:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 7 May 2021 06:58:54 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <7NSek1vJKe2IhUCPtObalVJqfjczfkD9KrgrTvtlROc=.523f6b98-149c-4307-ae13-bfb315b62f7f@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
 <7NSek1vJKe2IhUCPtObalVJqfjczfkD9KrgrTvtlROc=.523f6b98-149c-4307-ae13-bfb315b62f7f@github.com>
Message-ID: <qDE2NmiV31vp9uylkUpQEBHCwJtnSjFA_q947V41RX0=.6848a39b-61cc-4e01-add6-ecf12d9fb9d3@github.com>

On Fri, 7 May 2021 06:29:06 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncFlusher.hpp line 123:
>> 
>>> 121: 
>>> 122: typedef LinkedListDeque<AsyncLogMessage, mtLogging> AsyncLogBuffer;
>>> 123: typedef KVHashtable<LogFileOutput*, uintx, mtLogging> AsyncLogMap;
>> 
>> This is just to keep statistics of dropped messages per output, right? 
>> 
>> I think it would be a lot simpler just to add a reset-able counter to LogFileOutput directly. I don't even think it has to be uintx. 32bit should be sufficient (also, uintx makes no sense - do we somehow expect less message drops on 32bit platforms?)
>
> Yes, it is for the statistics of dropped messages.
> 
> AsyncLogMap looks a little cumbersome indeed, but the good side is that I isolate async logging things in logAsyncFlusher.hpp/cpp.  I manage not to pollute shared unified logging code. 
> 
> Another reason is that I can deliver the zero-cost promise when async logging is off.  If I move the counter to LogFileOutput, it will increase those object size a little bit.  In current implementation,  the singleton object LogAsyncFlusher is not created if -Xlog:async is absent.
> 
> Size wise, I think it's okay to to have 8 byte.  if a network-based device disappeared, who know how long asynclog thread  would block.  bigger counter is better.  Cost is almost same because the number of logFileOutput objects is usually less than 4.

I respect your "no costs promise" concern, but really this is no problem. We create exactly one LogFileOutput object per file sink; so usually we have one, maybe two of those if async=true. I think the costs of those counters would be bearable :)

I understand the concern of not polluting the UL code base. But here I think it does not apply, since you bring your patch upstream anyway, so async logging is now part of the UL code base.

wrt to counter size, okay lets use 64bit. But lets really use 64bit, also in 32bit VMs (so, use uint64_t instead of uintx).

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

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

From xliu at openjdk.java.net  Fri May  7 08:13:53 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 7 May 2021 08:13:53 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
Message-ID: <3cLCUYGyG2z7nv-UYrXhFbAq3rsc9XGxTpJSmj7TdbU=.4180ec68-507b-4ba3-9c32-0df81b4e30b5@github.com>

On Fri, 7 May 2021 06:13:19 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change option AsyncLogBufferEntries to AsyncLogBufferSize.
>   
>   AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
>   User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.

src/hotspot/share/logging/logFileOutput.cpp line 312:

> 310:   if (flusher != NULL) {
> 311:     flusher->enqueue(*this, decorations, msg);
> 312:     return 0;

should return -1 here. be consistent with `write(LogMessageBuffer::Iterator msg_iterator)` below.

src/hotspot/share/logging/logFileOutput.hpp line 41:

> 39:   static const char* const FileCountOptionKey;
> 40:   static const char* const FileSizeOptionKey;
> 41:   static const char* const AsyncOptionKey;

this is deprecated!

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

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

From xliu at openjdk.java.net  Fri May  7 08:13:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 7 May 2021 08:13:54 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
Message-ID: <ZVN2W9Z0_HMkh6Bz890hUhXSnKNkX-81Mu9SmKc3dtw=.8db56549-8ce9-4f8d-9f7b-26e74c6e95c5@github.com>

On Thu, 6 May 2021 14:55:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.
>
> test/hotspot/gtest/logging/test_asynclog.cpp line 44:
> 
>> 42: };
>> 43: 
>> 44: class AsyncLogTest : public LogTestFixture {
> 
> Unless you plan to add other code to this fixture I would prefer a regular RAII object like we do in hotspot, and naming it `AsyncModeMark`, and placing it at the start of each function instead. 
> 
> Reason: you can use EXPECT macros inside to test stuff and they fire as part of the test, its easier to debug, and it is common notation so hotspot devs know what this is without looking up rules about googletest fixtures.
> 
> But kudos for leaving clean state after your tests.

I tried but I found it's  difficult not to use LogTestFixture here for async logging tests.
 
The constructor and destructor of LogTestFixture help me do the chores. 
Without them, I can't use this set up function.
  `set_log_config(TestLogFileName, "logging=debug");`

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

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

From aph at openjdk.java.net  Fri May  7 08:23:53 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 7 May 2021 08:23:53 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: <xUHZSnsfMEbYwyS2fryrymLIVhA-Mq4FF30KZizo3x8=.04428a6c-4a83-43b5-bf30-2198076ff085@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
 <xUHZSnsfMEbYwyS2fryrymLIVhA-Mq4FF30KZizo3x8=.04428a6c-4a83-43b5-bf30-2198076ff085@github.com>
Message-ID: <lceWZ09xE3U67sRLmbUPsw3VubiPfjBRY6icibAt7DM=.d588647b-bb4d-4c85-8dd6-d2e654bd9abd@github.com>

On Thu, 29 Apr 2021 20:24:25 GMT, Carlos O'Donell <github.com+3019228+codonell at openjdk.org> wrote:

> Where does the requirement for monotonicity come from?

Semi-monotonicity, to be precise. In the spec of java.lang.Math,

"Besides accuracy at individual arguments, maintaining proper relations between the method at different arguments is also important. Therefore, most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements."

I wouldn't be surprised if the approximations we need in glibc meet this anyway. We just need to check.

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

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

From kbarrett at openjdk.java.net  Fri May  7 08:28:44 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 7 May 2021 08:28:44 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <rBhMEC0EIm2OznC2aiegQJj4MtP7zHUFQe14nFcWSvg=.cc302f84-9855-434b-89cc-59f3383182da@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

I've made some improvements to comments, responding to Thomas's suggestions. Ive also changed some of the naming around the injected java.lang.String flags, with modification now using test-and-set semantics (and named accordingly), i.e. returning true if already set rather than if changed.

I've not yet dealt with the merge conflict in Shenandoah, but it looks like it should be fairly easy.  Just waiting for more comments before dealing with merging updates.

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

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

From kbarrett at openjdk.java.net  Fri May  7 08:28:43 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 7 May 2021 08:28:43 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:

 - more comment improvements
 - improve naming and comments around injected String flags
 - fix some typos in comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3662/files
  - new: https://git.openjdk.java.net/jdk/pull/3662/files/2df362cb..656e2426

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

  Stats: 70 lines in 8 files changed: 8 ins; 2 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

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

From kbarrett at openjdk.java.net  Fri May  7 08:28:47 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 7 May 2021 08:28:47 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com>
Message-ID: <9jVZLn0ARJw8ZQH6zIyly1AVN9RF9HdQn8hvpDMqMLg=.dfd10f63-e445-44f9-a599-6c627404c64e@github.com>

On Tue, 4 May 2021 11:47:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>
> src/hotspot/share/classfile/javaClasses.hpp line 171:
> 
>> 169:   static inline bool is_latin1(oop java_string);
>> 170:   static inline bool no_deduplication(oop java_string);
>> 171:   static inline bool deduplication_requested(oop java_string);
> 
> Having a verb at the beginning like `is_deduplication_requested` sounds better.

"is_deduplication_requested" suggests there is currently a request, but this flag remains true even after the request is processed.

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

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

From kbarrett at openjdk.java.net  Fri May  7 08:30:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 7 May 2021 08:30:55 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com>
Message-ID: <YxITPycRRX5qN69EKTJQRBwkhmId2LviKSkAiTe1Xr8=.ce269a31-04dc-4801-8a87-c35c02353e63@github.com>

On Tue, 4 May 2021 11:46:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>
> src/hotspot/share/classfile/javaClasses.hpp line 170:
> 
>> 168:   static inline bool hash_is_set(oop string);
>> 169:   static inline bool is_latin1(oop java_string);
>> 170:   static inline bool no_deduplication(oop java_string);
> 
> That identifier is missing a verb to read better, but I do not have a good idea. Maybe it would be easier to use the negation of "no_deduplication", something like "may_deduplicate"?
> Feel free to ignore.

"may_deduplicate" would require internally flipping the sense, to account for the initial value being false because of zero-initialization.  I've changed it to "deduplication_forbidden"; hopefully that helps.

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

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

From aph at openjdk.java.net  Fri May  7 08:35:50 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 7 May 2021 08:35:50 GMT
Subject: RFR: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
In-Reply-To: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
References: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
Message-ID: <8uyfdoCBwLs-IuNDnVxukcWJ9Ab02yXmU6rOT0EZD2o=.95f5891d-aad9-4d09-8538-bb316c2db9f6@github.com>

On Thu, 6 May 2021 10:03:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
> without the additional 2*wordSize needed to store FP/LR (i.e. just the
> space required for the C1 locals).  When we pass this value to
> MacroAssembler build_frame and remove_frame we need to remember to add
> back the 2*wordSize.  This patch changes initial_frame_size_in_bytes()
> to return the full frame size including the space for FP/LR.  The PPC
> and S390 ports already do this, and it also matches the behaviour of
> C->output()->frame_size_in_bytes() in C2.
> 
> This change may seem a bit trivial in mainline but the Valhalla lworld
> branch makes more calls to build_frame/remove_frame in C1 and keeping
> track of whether "framesize" is with or without FP/LR quickly becomes
> confusing.
> 
> Tested tier1 on AArch64.  The only use of this function is as input to
> C1_MacroAssembler build_frame() and remove_frame() so seems safe.

Marked as reviewed by aph (Reviewer).

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

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

From aph at openjdk.java.net  Fri May  7 08:35:50 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 7 May 2021 08:35:50 GMT
Subject: RFR: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
In-Reply-To: <XZbFU0bi7WawyxGuJUlIMOvsq2BqbyVccSBYQTnJRE4=.0a8ac8a4-096a-4ce6-a1a6-3bc0ce2f1d39@github.com>
References: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
 <uf1Teb83LfitgTUnRQqcXLFvjq0GPUhSt4Zai-J93IU=.d3da50fa-6511-41e2-8c0f-806ae956b950@github.com>
 <XZbFU0bi7WawyxGuJUlIMOvsq2BqbyVccSBYQTnJRE4=.0a8ac8a4-096a-4ce6-a1a6-3bc0ce2f1d39@github.com>
Message-ID: <W0POFBfcLd8TRHACHBt8eDFhKLZh4KgHvM4dJAeRGWE=.a55b9173-3207-4312-8c77-11d01ce67f0c@github.com>

On Fri, 7 May 2021 01:48:43 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> > This calculation is the same as x86. Can you explain why it has to be changed on AArch64, but should not be changed on x86?
> 
> On AArch64 `C1_MacroAssembler::build_frame()` delegates to `MacroAssembler::build_frame()` which expects the total frame size. On x86 we build the frame directly in C1_MacroAssembler by doing roughly `__ push(rbp); __ decrement(rsp, frame_size_in_bytes);` so it's natural that `frame_size_in_bytes` shouldn't include the space for the frame pointer and the return address (which was already pushed by the `call` instruction). If we made this change on x86 we'd need to subtract `2*wordSize` from each increment/decrement of rsp which seems like a net loss.

OK, makes snse.

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

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

From sjohanss at openjdk.java.net  Fri May  7 08:51:15 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 08:51:15 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special [v2]
In-Reply-To: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
Message-ID: <nx5HdaWExeMQUHgm-TAz2J_A5mYxbHXO_DOoVDXrj1U=.023dcdbf-7e43-4f72-98d4-5fc044b0a14c@github.com>

> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
> 
> **Summary**
> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
> 
> **Testing**
> Local testing together with parts of PR #1153. Mach5 tier 1-3

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

  Thomas review. Update assert.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3878/files
  - new: https://git.openjdk.java.net/jdk/pull/3878/files/fc36939e..1afa0013

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

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

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

From xliu at openjdk.java.net  Fri May  7 09:09:56 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 7 May 2021 09:09:56 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
Message-ID: <mZ9X1vw07nDxGejMBPYom8_aUApb_DUhUH1s8Y8AbUo=.7225867b-3993-4561-897a-9ef2727862c1@github.com>

On Thu, 6 May 2021 15:20:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The base class is unaware of the fact that you keep track of the list tail here. If used incorrectly (eg calling base class removal functions) you could damage this structure, because the tail node gets removed.

LinkedListDeque "private" inherits LinkedListImpl. They are not 'is-a' relationship.  LinkedListDeque just borrows some code from LinkedListImpl in its implementation.  Client can't sabotage "deque"  integrity using LinkedList's API. 

Actually,  my design target is a generic deque based on linkedlist.  Linked list can give me pop_all() in O(1).  you can think it of a smart `swap`. 

I acknowledge that problem you described. That's the cost to use ADT(Abstract Data Type). Even STL containers  sometimes are cumbersome.  I would like to hear other reviewers opinions about this. Shall I customize my own data structure or try to use ADT?  

I have fixed most issues in linkedlist.hpp in prior commits.  If @kimbarrett allows me to use move constructor, I can even remove `AsyncLogMessage::destroy`, which is just compromise to avoid copying.

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

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

From ngasson at openjdk.java.net  Fri May  7 09:23:52 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 7 May 2021 09:23:52 GMT
Subject: Integrated: 8266609: AArch64: include FP/LR space in
 LIR_Assembler::initial_frame_size_in_bytes()
In-Reply-To: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
References: <A6pno4VgtNFZLBmIclujMcdqjmKrQmD5gDDbUKMAShE=.9afcea71-40fc-480f-818f-29bd15ce54e3@github.com>
Message-ID: <jp6qTILKnXFZYO5THzB7GbQ9ER_9L1h0X07m8uR2SV8=.09003be9-3774-43e7-8d86-26b8a4588f2c@github.com>

On Thu, 6 May 2021 10:03:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
> without the additional 2*wordSize needed to store FP/LR (i.e. just the
> space required for the C1 locals).  When we pass this value to
> MacroAssembler build_frame and remove_frame we need to remember to add
> back the 2*wordSize.  This patch changes initial_frame_size_in_bytes()
> to return the full frame size including the space for FP/LR.  The PPC
> and S390 ports already do this, and it also matches the behaviour of
> C->output()->frame_size_in_bytes() in C2.
> 
> This change may seem a bit trivial in mainline but the Valhalla lworld
> branch makes more calls to build_frame/remove_frame in C1 and keeping
> track of whether "framesize" is with or without FP/LR quickly becomes
> confusing.
> 
> Tested tier1 on AArch64.  The only use of this function is as input to
> C1_MacroAssembler build_frame() and remove_frame() so seems safe.

This pull request has now been integrated.

Changeset: 71b8ad45
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71b8ad45b4de6836e3bb2716ebf136f3f8ea2198
Stats:     12 lines in 4 files changed: 2 ins; 4 del; 6 mod

8266609: AArch64: include FP/LR space in LIR_Assembler::initial_frame_size_in_bytes()

Reviewed-by: aph

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

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

From neliasso at openjdk.java.net  Fri May  7 09:29:51 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 7 May 2021 09:29:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v6]
In-Reply-To: <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
Message-ID: <cmOrcsj532yCJP1x4bxdC6mY4F9EsiB9QjPIVzZ7U4o=.b3e5eabe-90e5-4bd4-b0e0-84379030dcd8@github.com>

On Thu, 6 May 2021 17:12:37 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove checking AVX_512 in vbroadcastf128

I find this test for Adler32: test/hotspot/jtreg/compiler/intrinsics/zip/TestAdler32.java

Will there be a benchmark added to micros?

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

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

From iwalulya at openjdk.java.net  Fri May  7 09:33:05 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 7 May 2021 09:33:05 GMT
Subject: RFR: 8266637: CHT: Add insert_and_get method
Message-ID: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>

Hi all,

Please review this change to add an `insert_get` method to the CHT.  The method combines `insert()` and `get()` methods to decrease the amount of global synchronization needed for `get()` calls after an `insert` call. 

Testing: tier1-3

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

Commit messages:
 - fix memory leak
 - change comment
 - change comment
 - add insert_get method and gtest

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

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

From stuefe at openjdk.java.net  Fri May  7 10:05:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 7 May 2021 10:05:55 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <KSZNSUS9VncjrGd0MzwqszHKlwFBeRhsXWOyiKi7XF8=.07ec0442-77e7-4c98-8371-e3d1761c7905@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <KSZNSUS9VncjrGd0MzwqszHKlwFBeRhsXWOyiKi7XF8=.07ec0442-77e7-4c98-8371-e3d1761c7905@github.com>
Message-ID: <CsjJi3gDGs1X30PtsjfAlzfGSpwkN1I-Lwl5grPeHl0=.af3f14c2-6706-47fa-8da4-ca41d2f2dd6c@github.com>

On Fri, 26 Mar 2021 09:17:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change option AsyncLogBufferEntries to AsyncLogBufferSize.
>>   
>>   AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
>>   User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 81:
> 
>> 79: LogAsyncFlusher* LogAsyncFlusher::_instance = NULL;
>> 80: 
>> 81: void LogAsyncFlusher::initialize() {
> 
> I don't think you need this. Please merge the initialization into `LogAsyncFlusher::instance()` (see my comments on your changes in `init.cpp`).

In contrast to Volker I think an explicit initialization is fine and follows the established pattern for other subsystems. However, I would:
- assert for _instance == NULL and remove the condition. This should only be called once.
- no need for Atomics here since we do this during VM init.

And while writing this, I realize this would conflict with the gtest fixture where you switch this on or off several time in one process. I propose you switch those gtests - only those testing the LogAsyncFlusher, not those testing the Deque etc - as TEST_OTHER_VM. 

Which arguably we should do for all logging gtests, not only yours, if they fiddle with global VM settings. In other words, it should be possible to run the gtests with -Xlog:... options and the gtests should still pass, including all log tests. Today, this is not the case.

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

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

From stuefe at openjdk.java.net  Fri May  7 10:05:57 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 7 May 2021 10:05:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
Message-ID: <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>

On Fri, 7 May 2021 06:13:19 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change option AsyncLogBufferEntries to AsyncLogBufferSize.
>   
>   AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
>   User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.

src/hotspot/share/logging/logAsyncFlusher.cpp line 189:

> 187:     LogAsyncFlusher* self = _instance;
> 188: 
> 189:     Atomic::release_store<LogAsyncFlusher*, LogAsyncFlusher*>(&_instance, nullptr);

IIUC the mechanism you signal "async"-ness to the logging callsites with is via this pointer being NULL or not, right?

I am not sure this is safe wrt to lost log output on termination. This is not a big deal, but it would be nice if we lost no output from concurrent logging when terminating and switching over to non-async mode.

Proposal: 

in `LogFileOutput::write`, instead of querying this pointer for NULL, just call `LogAsyncFlusher::enqueue()` unconditionally and let enqueue() return a state whether write succeeded or not. In that function, return false if flusher is terminated or not active at all - in which case you do the normal synchronized writing.

Thinking this through, one could even scratch the LogAsyncBuffer dynamic allocation and make it either a static global object or even an AllStatic, with all static methods. As a bonus, you can replace the instance variable, as well as the NULL tests and possibly the Thread::current(), with access to either static LogAsyncBuffer functions or to a global static LogAsyncBuffer singleton.

src/hotspot/share/logging/logAsyncFlusher.cpp line 206:

> 204: 
> 205: LogAsyncFlusher* LogAsyncFlusher::instance() {
> 206:   if (Thread::current_or_null() != nullptr) {

I don't understand why this depends on the existence of a current thread? Ideally we should be able to log just fine in corner cases, e.g. when thread is detached or if we have an error (during signal handling e..g.)

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

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

From alanb at openjdk.java.net  Fri May  7 10:07:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 7 May 2021 10:07:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v12]
In-Reply-To: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com>
Message-ID: <w_Wd3vda-lUI_nkUq5OVIY5j1Ft6286VZ0Wm4OGJO58=.34175119-86cb-417f-a9d2-0fe0ed3875fe@github.com>

On Thu, 6 May 2021 14:23:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 72:

> 70:  *
> 71:  * <pre>{@code
> 72: try (ResourceScope scope = ResourceScope.ofConfined()) {

The example might be out of date, I assume this should be newConfinedScope.

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

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

From stuefe at openjdk.java.net  Fri May  7 10:33:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 7 May 2021 10:33:55 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
Message-ID: <lfkwGm9OKaffWF32feGpYCBdR1ClV4fIWWS8dj_xbd0=.5307c3f4-ff43-4158-98ab-5da2e7c8b41b@github.com>

On Fri, 7 May 2021 06:13:19 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change option AsyncLogBufferEntries to AsyncLogBufferSize.
>   
>   AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
>   User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.

Hi Xin,

continuing the review. I concentrated on startup and termination/abort.

---

One general thing, I think it would be good to limit this to:
- we do initialize only once, if needed, during VM startup.
- we terminate only once, during VM shutdown.
In other words, exclude the possibility to switch async state at runtime, eg via jcmd. I think this would make matters simpler.

---

About synchronization: I don't understand the reasoning behind having a periodic flush. Would an implementation which just flushes if output is available not be less complex and actually better? Why make the flusher thread wake up twice a second if there is nothing to do? OTOH why wait 500ms if there is actually output to be printed?

IMHO this would make sense both for dense printing and sparse printing. When printing a lot, we'd keep the flusher busy without artificial waits. When not much happens, flusher does not need to be scheduled.

Furthermore, IIUC this wait introduces an artificial 500ms delay on VM shutdown, since you have this handshake with the flusher thread which does an unconditional wait. I don't think we should wait here, especially not for a thread which puts in an artificial delay.

Thanks, Thomas

p.s. code is well written und good to understand.

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

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

From stuefe at openjdk.java.net  Fri May  7 10:33:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 7 May 2021 10:33:55 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <mZ9X1vw07nDxGejMBPYom8_aUApb_DUhUH1s8Y8AbUo=.7225867b-3993-4561-897a-9ef2727862c1@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
 <mZ9X1vw07nDxGejMBPYom8_aUApb_DUhUH1s8Y8AbUo=.7225867b-3993-4561-897a-9ef2727862c1@github.com>
Message-ID: <2bOg32W7Xqra0xt96bgpSXzheV109X9eYinHTtflsw8=.b8775614-cc90-4d02-bb42-869a79acd65c@github.com>

On Fri, 7 May 2021 09:06:50 GMT, Xin Liu <xliu at openjdk.org> wrote:

> > The base class is unaware of the fact that you keep track of the list tail here. If used incorrectly (eg calling base class removal functions) you could damage this structure, because the tail node gets removed.
> 
> LinkedListDeque "private" inherits LinkedListImpl. They are not 'is-a' relationship. LinkedListDeque just borrows some code from LinkedListImpl in its implementation. Client can't sabotage "deque" integrity using LinkedList's API.

Okay, I see, I missed the private. 

> 
> Actually, my design target is a generic deque based on linkedlist. Linked list can give me pop_all() in O(1). you can think it of a smart `swap`.

I agree, that is fine, but you don't even need the move() operation. I mean, as Robbin proposed, you could just have two instances of this FIFO buffer somewhere and swap them around.

> 
> I acknowledge that problem you described. That's the cost to use ADT(Abstract Data Type). Even STL containers sometimes are cumbersome. I would like to hear other reviewers opinions about this. Shall I customize my own data structure or try to use ADT?
> 
> I have fixed most issues in linkedlist.hpp in prior commits. If @kimbarrett allows me to use move constructor, I can even remove `AsyncLogMessage::destroy`, which is just compromise to avoid copying.

I am very biased here because I often prefer handwritten code to these containers, since the complexity and runtime overhead often eats up the advantage of using generic code. That's just me, Kim may have a totally different opinion. Maybe its just this implementation. Eg I like very much the kernel list implementation, both generic and efficient.

In this case, using that ADT means:
- at least one unnecessary copy step when filling the list node
- one unnecessary dynamic allocation, since the node needs to be allocated. This is also one additional (well hidden) call to os::malloc, which is another barrier for ever making UL reentrant-safe wrt the hotspot allocation layer. 

But I wont fight you on this, especially since we already talked about improving this storage in some future RFE. So leave it in if you prefer.

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

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

From mcimadamore at openjdk.java.net  Fri May  7 11:18:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 7 May 2021 11:18:21 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v13]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <d13dhw_A-44iZXwSPNuuG316L2Cc-x4WRUaLF086INM=.2dfadd42-40e4-448f-84b4-b2dd65eaa128@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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

  Fix issue in snippet in package-info

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/926229ed..1ce6366a

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

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

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

From sjohanss at openjdk.java.net  Fri May  7 11:36:52 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 11:36:52 GMT
Subject: RFR: 8266349: Pass down requested page size to
 reserve_memory_special [v2]
In-Reply-To: <yqVVYqJl52AlJ_GMVtrUC7IAglnu3TaATvkKeqPWzVM=.ad6a5d74-8e5c-44c2-a65b-730e1d094edf@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
 <5sIUtZvkc2XlQl_-ad53K_8xw_emJw3U8EmX_8Ygwb4=.d2b83a5b-220a-47cf-8c16-7f95ccb710ef@github.com>
 <yqVVYqJl52AlJ_GMVtrUC7IAglnu3TaATvkKeqPWzVM=.ad6a5d74-8e5c-44c2-a65b-730e1d094edf@github.com>
Message-ID: <a44IQilAbmNAlyoPW7AOyRqKB05hzVnDvT5uOf7NrbA=.876e10cb-1ac8-4e62-9e7d-e439be42000a@github.com>

On Wed, 5 May 2021 13:50:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Very good.
>>> 
>> 
>> Thanks =)
>> 
>>> This is not only cosmetic but functional, no? Since before we would always os::large_page_size(); now, in the case of ReservedSpace::ReservedSpace(size), we use whatever os::page_size_for_region wants us to use. Lets see if any errors creep up.
>>> 
>> 
>> I think this should not change functionality. Before I started my refactoring we did not have `ReservedSpace::ReservedSpace(size)` but this function below where the second parameter was optional. As you can see, if no `preferred_page_size` was given we would use `os::page_size_for_region_unaligned(size, 1)` which is what now is done in `ReservedSpace::ReservedSpace(size)`:
>> 
>> ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size) : _fd_for_heap(-1) {
>>   bool has_preferred_page_size = preferred_page_size != 0;
>>   // Want to use large pages where possible and pad with small pages.
>>   size_t page_size = has_preferred_page_size ? preferred_page_size : os::page_size_for_region_unaligned(size, 1);
>>   bool large_pages = page_size != (size_t)os::vm_page_size();
>>   ...
>> 
>> 
>> And if we end up with a page size that isn't large we will never get down into `reserve_memory_special(...)`. Does this sound correct, or did I miss your point?
>
>> > Very good.
>> 
>> Thanks =)
>> 
>> > This is not only cosmetic but functional, no? Since before we would always os::large_page_size(); now, in the case of ReservedSpace::ReservedSpace(size), we use whatever os::page_size_for_region wants us to use. Lets see if any errors creep up.
>> 
>> I think this should not change functionality. Before I started my refactoring we did not have `ReservedSpace::ReservedSpace(size)` but this function below where the second parameter was optional. As you can see, if no `preferred_page_size` was given we would use `os::page_size_for_region_unaligned(size, 1)` which is what now is done in `ReservedSpace::ReservedSpace(size)`:
>> 
>> ```
>> ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size) : _fd_for_heap(-1) {
>>   bool has_preferred_page_size = preferred_page_size != 0;
>>   // Want to use large pages where possible and pad with small pages.
>>   size_t page_size = has_preferred_page_size ? preferred_page_size : os::page_size_for_region_unaligned(size, 1);
>>   bool large_pages = page_size != (size_t)os::vm_page_size();
>>   ...
>> ```
>> 
>> And if we end up with a page size that isn't large we will never get down into `reserve_memory_special(...)`. Does this sound correct, or did I miss your point?
> 
> No, this sounds right.

Thanks @tstuefe and @mgkwill for reviewing.

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

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

From sjohanss at openjdk.java.net  Fri May  7 11:36:53 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 11:36:53 GMT
Subject: Integrated: 8266349: Pass down requested page size to
 reserve_memory_special
In-Reply-To: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
References: <30YsuhYFqeMPq5ld-vs4AcWZ_LsSHIZe7kjpgZIXxJI=.c022fef9-b426-4d47-969f-8ad9251d4fac@github.com>
Message-ID: <aS7U5e4yotVJ__11NtcVyJAQEXfClUfJ9ddXErNXW18=.62e54387-1823-4657-8a2d-799ce222a348@github.com>

On Wed, 5 May 2021 10:29:32 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement that passes the requested page size in `ReservedSpace` down to the OS-layer.
> 
> **Summary**
> After recent refactoring `ReservedSpace` now store the page size used for a reservation. To make this more consistent this change passes down the page size from the `ReservedSpace` down to the OS-layer when using explicit large pages. Currently this is not really needed because we only support one large page size during the lifetime of the JVM, but this will change with PR #1153. That PR will be simpler to implement if the requested page size is passed down from the layers above. 
> 
> **Testing**
> Local testing together with parts of PR #1153. Mach5 tier 1-3

This pull request has now been integrated.

Changeset: 2798b0d9
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2798b0d98ab4191fc94e210d57422854cf13f11e
Stats:     38 lines in 10 files changed: 4 ins; 0 del; 34 mod

8266349: Pass down requested page size to reserve_memory_special

Reviewed-by: stuefe, mgkwill

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

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

From zgu at openjdk.java.net  Fri May  7 12:36:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 7 May 2021 12:36:53 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64
In-Reply-To: <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
 <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
Message-ID: <FWojWvyXJR47qji7jS63POPC9slszN47yH70KB_fTf8=.750f5a6f-a0f8-466d-a0c1-8efabf322b5b@github.com>

On Fri, 7 May 2021 03:19:08 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> JDK-8263427 missed corresponding changes for aarch64.
>> 
>> LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah on Macosx/AArch64
>> - [ ] hotspot_gc_shenandoah on Linux 64/AArch64
>
> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 249:
> 
>> 247:   } else {
>> 248:     if (dst == rscratch1) {
>> 249:       __ push(rscratch1, sp);
> 
> Could we avoid the push/pop by passing in an extra temporary? We have `tmp1` available in `ShenandoahBarrierSetAssembler::load_at()` which is the only place that calls this.

Unfortunately, tmp1 == noreg here.

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

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

From sjohanss at openjdk.java.net  Fri May  7 12:52:50 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 12:52:50 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
Message-ID: <FofFsKziOd1kRTrvEDgyfDBpYqc7hMlEuL_Ln7qLW-k=.ea80c0aa-b149-4845-a1f5-b65c340cabc6@github.com>

On Thu, 6 May 2021 14:02:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Adding the assertion, and fixing a benign violation.

Changes looks good. What kind of testing have you done to ensure nothing else triggers the assertion?

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

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

From sjohanss at openjdk.java.net  Fri May  7 12:59:56 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 12:59:56 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v31]
In-Reply-To: <MHqbs77S09Zx7IjNoEyi9xjQ1BgpDTroLPyhJwUzbDs=.1b9b1ac1-4e14-4c18-925e-889983d269ce@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <MHqbs77S09Zx7IjNoEyi9xjQ1BgpDTroLPyhJwUzbDs=.1b9b1ac1-4e14-4c18-925e-889983d269ce@github.com>
Message-ID: <O8Z_AECybsjoSnkSngeyWX-1tfcAmvyBRiRc2-M9JCE=.0694462a-ecff-4ac2-8fea-d3018e71232e@github.com>

On Wed, 5 May 2021 17:51:25 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extranous vm_page_size check
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Integrated #3878 now, so please merge those changes and I will pick this up and do some additional testing. I've been testing my changes with yours quite a bit already and everything seems to work. So hopefully we can get this in fairly soon.

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

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

From stuefe at openjdk.java.net  Fri May  7 13:14:12 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 7 May 2021 13:14:12 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <ZVN2W9Z0_HMkh6Bz890hUhXSnKNkX-81Mu9SmKc3dtw=.8db56549-8ce9-4f8d-9f7b-26e74c6e95c5@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
 <ZVN2W9Z0_HMkh6Bz890hUhXSnKNkX-81Mu9SmKc3dtw=.8db56549-8ce9-4f8d-9f7b-26e74c6e95c5@github.com>
Message-ID: <HXGDBUoZPBTIBZpjrvq-5-2ugUCouv5M9XWyVEkMpDA=.dd7d46cd-c0d6-4561-ba65-88c499c6dd8c@github.com>

On Fri, 7 May 2021 08:10:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> test/hotspot/gtest/logging/test_asynclog.cpp line 44:
>> 
>>> 42: };
>>> 43: 
>>> 44: class AsyncLogTest : public LogTestFixture {
>> 
>> Unless you plan to add other code to this fixture I would prefer a regular RAII object like we do in hotspot, and naming it `AsyncModeMark`, and placing it at the start of each function instead. 
>> 
>> Reason: you can use EXPECT macros inside to test stuff and they fire as part of the test, its easier to debug, and it is common notation so hotspot devs know what this is without looking up rules about googletest fixtures.
>> 
>> But kudos for leaving clean state after your tests.
>
> I tried but I found it's  difficult not to use LogTestFixture here for async logging tests.
>  
> The constructor and destructor of LogTestFixture help me do the chores. 
> Without them, I can't use this set up function.
>   `set_log_config(TestLogFileName, "logging=debug");`

I see what you mean. I have thought about this some more. 

Unfortunately this requires you to be able to initialize and shutdown async logging at arbitrary times in the middle of VM life. Which normally would not be necessary. Not a big deal, but here is a slightly different proposal (and its just a proposal, I leave it up to you if you take this):

Instead of starting up and shutting down async logging at the start/end of a test (or, instead of the TEST_OTHER_VM proposal I did earlier), how about this:

1) Change your tests to not modify logging options. No fixture, no setup/teardown, no setup_logging(). Leave the tests passive: In the tests, you just react on those options (eg skipping AsyncLogTests if async logging is disabled)
2) Instead, you hand in all logging options you need from the outside via command line into the gtestLauncher. 
3) rename your tests to start with "Log..." like all other UL gtests. 
4) Then, add a gtest run configuration to the gtest jtreg wrapper: add a configuration with async=true and lots of logging. Limit on this command line the gtests to only run UL gtests ('--gtest_filter=Log*' )

This is actually very easy, I have done this for large page tests and metaspace test, among other things. See `test/hotspot/jtreg/gtest/LargePageGtests.java` or `test/hotspot/jtreg/gtest/MetaspaceGtests.java`. 

The advantage would be:
- no need to fiddle with log options in your tests, and to reinstate them at teardown
- no danger of accidentally disturbing other neighboring gtests, if yours is executed in parallel to others (we don't do this today but its possible).
- You execute all logging gtests - not only yours - with both async=false and async=true, and this is a better test coverage. This would be a nice stress test for async logging.

I understand if you don't want to do this now. This would be a fine future RFE (since actually, it should be done for all UL tests, not only yours).

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

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

From sjohanss at openjdk.java.net  Fri May  7 14:18:06 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 14:18:06 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
Message-ID: <_WiAnSf_ZT-P_Jd7liT2wTb6zjq0Yk-zJYvjkipY9I8=.602b3992-0c72-4768-9390-893fabe10749@github.com>

On Thu, 6 May 2021 14:02:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Adding the assertion, and fixing a benign violation.
> 
> Test: tier1-7; no violation of this assertion.

Marked as reviewed by sjohanss (Reviewer).

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

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

From aph at openjdk.java.net  Fri May  7 14:34:00 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 7 May 2021 14:34:00 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64
In-Reply-To: <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
 <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
Message-ID: <5l0vBLGhIxGcPTyRnM2o3fVnK03myq0CZoB7PipwMO0=.24f80b40-78c1-4f82-98e2-6d34febc8de9@github.com>

On Fri, 7 May 2021 03:19:08 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> JDK-8263427 missed corresponding changes for aarch64.
>> 
>> LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah on Macosx/AArch64
>> - [ ] hotspot_gc_shenandoah on Linux 64/AArch64
>
> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 249:
> 
>> 247:   } else {
>> 248:     if (dst == rscratch1) {
>> 249:       __ push(rscratch1, sp);
> 
> Could we avoid the push/pop by passing in an extra temporary? We have `tmp1` available in `ShenandoahBarrierSetAssembler::load_at()` which is the only place that calls this.

We don't need a register. It's just a TBNZ and a TBZ, isn't it?

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

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

From zgu at openjdk.java.net  Fri May  7 15:09:52 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 7 May 2021 15:09:52 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64
In-Reply-To: <FWojWvyXJR47qji7jS63POPC9slszN47yH70KB_fTf8=.750f5a6f-a0f8-466d-a0c1-8efabf322b5b@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
 <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
 <FWojWvyXJR47qji7jS63POPC9slszN47yH70KB_fTf8=.750f5a6f-a0f8-466d-a0c1-8efabf322b5b@github.com>
Message-ID: <fhRKGqqXcUQ6yVL3Kh623Pe-hwjeaSz-Ol57plriUHs=.566b15a9-d9d6-4f79-9913-3abe5a96d51b@github.com>

On Fri, 7 May 2021 12:33:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> We don't need a register. It's just a TBNZ and a TBZ, isn't it?
>
> Unfortunately, tmp1 == noreg here.

so, this is better alternative?
    `Label lrb;`
    `__ tbnz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, lrb);`
    `__ tbnz(rscratch2, ShenandoahHeap::WEAK_ROOTS_BITPOS, lrb);`
    `__ b(heap_stable);`
    `__ bind(lrb);`

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

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

From akozlov at openjdk.java.net  Fri May  7 15:49:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 7 May 2021 15:49:17 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java crashes
 with SIGBUS
Message-ID: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>

Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.

The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.

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

Commit messages:
 - Fix java/foreign SIGBUS on macos/aarch64

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

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

From mgkwill at openjdk.java.net  Fri May  7 16:16:22 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 7 May 2021 16:16:22 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:

 - Remove reserve_memory_special_huge_tlbfs mods except assert
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Merge branch 'master' into update_hlp
 - Remove extranous vm_page_size check
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - kstefanj review
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Set LargePageSizeInBytes to largepage upper limit
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Fix merge
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Merge branch 'master' into update_hlp
 - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

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

Changes: https://git.openjdk.java.net/jdk/pull/1153/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=31
  Stats: 126 lines in 2 files changed: 63 ins; 47 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153

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

From mgkwill at openjdk.java.net  Fri May  7 16:23:01 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 7 May 2021 16:23:01 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v31]
In-Reply-To: <O8Z_AECybsjoSnkSngeyWX-1tfcAmvyBRiRc2-M9JCE=.0694462a-ecff-4ac2-8fea-d3018e71232e@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <MHqbs77S09Zx7IjNoEyi9xjQ1BgpDTroLPyhJwUzbDs=.1b9b1ac1-4e14-4c18-925e-889983d269ce@github.com>
 <O8Z_AECybsjoSnkSngeyWX-1tfcAmvyBRiRc2-M9JCE=.0694462a-ecff-4ac2-8fea-d3018e71232e@github.com>
Message-ID: <dBIMTGokcSl8kXf8Js8Q4PaeBBNfA8M47Mq7q6vR5LU=.66f1a683-9d09-4254-8620-424b585fca21@github.com>

On Fri, 7 May 2021 12:57:13 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Integrated #3878 now, so please merge those changes and I will pick this up and do some additional testing. I've been testing my changes with yours quite a bit already and everything seems to work. So hopefully we can get this in fairly soon.

@kstefanj Thanks! Draft of changes requested here. Any comments/suggestions are appreciated.

?? Maybe a bug got through to main branch, but I can't build locally after master merge. Error coming from G1GCPhaseTimes::log_phase. So I wasn't able to run some tests locally. Pushed to see if it builds and passes tests form github actions env.


make: *** [/home/mgkwill/src/git/jdk/make/Init.gmk:186: test] Error 2
[mgkwill at mgkwill-desk jdk]$ make CONF=linux-x86_64-server-release                                                                                                           Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
In member function 'void G1GCPhaseTimes::log_phase(WorkerDataArray<double>*, uint, outputStream*, bool) const',
    inlined from 'void G1GCPhaseTimes::trace_phase(WorkerDataArray<double>*, bool, uint) const' at /home/mgkwill/src/git/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:355:14:

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Fri May  7 16:42:30 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Fri, 7 May 2021 16:42:30 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> For the following benchmark:
> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> 
> The optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

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

  Add @run case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/72a0d3f3..3851c602

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

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

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

From kbarrett at openjdk.java.net  Fri May  7 18:04:36 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 7 May 2021 18:04:36 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
Message-ID: <Bxy1cQWv1um9l2ZcnaA-iI8ZY7oQnR3uEvF1zSU7ioQ=.7f230148-23d3-4f9d-b575-bef643cbb0ba@github.com>

On Thu, 6 May 2021 14:02:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Adding the assertion, and fixing a benign violation.
> 
> Test: tier1-7; no violation of this assertion.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1Allocator.cpp line 460:

> 458:   // chunk if we don't yet cross the boundary, but the remainder would be too
> 459:   // small to fill.
> 460:   HeapWord* new_top = old_top + word_size;

Pre-existing but related to the change - What, if anything, prevents the calculation of new_top from overflowing or detects that happened.  The usual way we do such calculations safely involves first checking that `(_max - old_top) <= word_size` or something similar.  I don't see anything to prevent that, and if nothing does then the various checks and calculations involving new_top are suspect.

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Fri May  7 18:21:25 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Fri, 7 May 2021 18:21:25 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
Message-ID: <fCP14ksrLb4-td3tfN49GOXBQj5r_k7qXrNy1D18LF0=.f67bb373-15db-4e7e-99cb-1c126793d771@github.com>

On Fri, 7 May 2021 16:42:30 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @run case

Hi Nils,
I modified TestAdler32.java by adding a @run case using -XX:+UseAdler32Intrinsics, and saw the run time shorted by 4.76x on my machine.

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

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

From sviswanathan at openjdk.java.net  Fri May  7 18:21:26 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 7 May 2021 18:21:26 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v6]
In-Reply-To: <cmOrcsj532yCJP1x4bxdC6mY4F9EsiB9QjPIVzZ7U4o=.b3e5eabe-90e5-4bd4-b0e0-84379030dcd8@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <ek5zoW4MZ5I-JkUibgwcm_g-VwBHv4o_7ryQhWMYAIo=.1848ff5d-fa5f-4084-bd4c-5c3e81fffb56@github.com>
 <cmOrcsj532yCJP1x4bxdC6mY4F9EsiB9QjPIVzZ7U4o=.b3e5eabe-90e5-4bd4-b0e0-84379030dcd8@github.com>
Message-ID: <OiLB_NKhwUz8xKq8Dwf7eNC93jkSrZG-bXOwettFs9I=.75e6b42e-3fcb-4971-a540-e7fd0864b484@github.com>

On Fri, 7 May 2021 09:26:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove checking AVX_512 in vbroadcastf128
>
> I find this test for Adler32: test/hotspot/jtreg/compiler/intrinsics/zip/TestAdler32.java
> 
> Will there be a benchmark added to micros?

@neliasso  Could you please help review this patch. Jatin and I have looked at it and it looks good to us but we are not official reviewers. The algorithm is from https://github.com/intel/isa-l/blob/master/igzip/adler32_avx2_4.asm. 

Also the jmh micro http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java is from Pengfei Li @pfustc, shared as part of JDK-8216259 aarch64 optimization.  Maybe Pengfei can contribute that to the OpenJDK.

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Fri May  7 18:26:12 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Fri, 7 May 2021 18:26:12 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
Message-ID: <1JnKSpxAwilBL-ByTVm1i6pOkec0b_A4xb-s5LtTd8o=.2808324d-5362-4e75-b40d-35b8dfacc42e@github.com>

On Fri, 7 May 2021 16:42:30 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @run case

The following tests have been run on both Linux and Windows:
unit test of various buf sizes, 512, 1024, 2048, 4096, 8192, ... etc to compare the intrinsic vs base c++ impl.
jmh - http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
jtreg - test-tier1

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

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

From github.com+471021+marschall at openjdk.java.net  Fri May  7 19:18:47 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Fri, 7 May 2021 19:18:47 GMT
Subject: RFR: 8252530: Fix inconsistencies in hotspot whitebox
Message-ID: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>

Replace the runtime check and remove the "InVmBuild" suffix as described in the bug.

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

Commit messages:
 - 8252530: Fix inconsistencies in hotspot whitebox

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

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

From sjohanss at openjdk.java.net  Fri May  7 19:45:09 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 19:45:09 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <xgdGSr-bwrzDRcR_kcgQsxAJZGrNHoeOcEoo7OBycMA=.6382ec9c-21c9-49aa-9c3c-65446d3b8124@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

I just built your PR branch locally and it works fine, as well as on GHA. Try doing a `make clean`, some things have change in the classes listed in that output and you might have to do a full re-compile.

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

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

From mgkwill at openjdk.java.net  Fri May  7 19:57:13 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 7 May 2021 19:57:13 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <xgdGSr-bwrzDRcR_kcgQsxAJZGrNHoeOcEoo7OBycMA=.6382ec9c-21c9-49aa-9c3c-65446d3b8124@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <xgdGSr-bwrzDRcR_kcgQsxAJZGrNHoeOcEoo7OBycMA=.6382ec9c-21c9-49aa-9c3c-65446d3b8124@github.com>
Message-ID: <nPT38fKAmRcFyBS2AzymH1K_67cNKkC_G3ry6HiyEIM=.d8fcc47c-10f6-4f45-80ae-7b06fe94af07@github.com>

On Fri, 7 May 2021 19:33:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> I just built your PR branch locally and it works fine, as well as on GHA. Try doing a `make clean`, some things have change in the classes listed in that output and you might have to do a full re-compile.

Thanks @kstefanj .

I'll give that a try again. The first thing I attempted was make clean and re-compile. If it works for you and github actions, it must be in my env.

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

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

From sjohanss at openjdk.java.net  Fri May  7 20:55:24 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 7 May 2021 20:55:24 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <YVcvYijv59RSIWZlX-waJf5ekIBFjVHIx2QHaFG3gPs=.22382b36-4c69-4d9c-be25-c57fdbfe7f1f@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

> I cloned openjdk/jdk and configured and `make` on main branch and I get the same result. Could it be my toolchain versions and recent changes clashing? `cc1plus: all warnings being treated as errors`?

Could be something like that. At least good to know it's not connected to the code in this PR.

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

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

From mgkwill at openjdk.java.net  Fri May  7 20:51:11 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 7 May 2021 20:51:11 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <nPT38fKAmRcFyBS2AzymH1K_67cNKkC_G3ry6HiyEIM=.d8fcc47c-10f6-4f45-80ae-7b06fe94af07@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <xgdGSr-bwrzDRcR_kcgQsxAJZGrNHoeOcEoo7OBycMA=.6382ec9c-21c9-49aa-9c3c-65446d3b8124@github.com>
 <nPT38fKAmRcFyBS2AzymH1K_67cNKkC_G3ry6HiyEIM=.d8fcc47c-10f6-4f45-80ae-7b06fe94af07@github.com>
Message-ID: <R99nTE-Fxaa1ycwad9WisVkeLiBwlAq33xVkMD-wnlk=.1cd1ca9c-eea3-4588-8194-b56326db0824@github.com>

On Fri, 7 May 2021 19:40:35 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

> > I just built your PR branch locally and it works fine, as well as on GHA. Try doing a `make clean`, some things have change in the classes listed in that output and you might have to do a full re-compile.
> 
> Thanks @kstefanj .
> 
> I'll give that a try again. The first thing I attempted was make clean and re-compile. If it works for you and github actions, it must be in my env.

Yeah weirdly a `make clean` and `make` still has build issue:

$ make clean CONF=linux-x86_64-server-release
Building target 'clean' in configuration 'linux-x86_64-server-release'
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
Cleaning bootcycle-build build artifacts ... done
Cleaning test-results build artifacts ... done
Cleaning test-support build artifacts ... done
Cleaning test build artifacts ... done
Cleaning buildtools build artifacts ... done
Cleaning support build artifacts ... done
Cleaning support/images build artifacts ... done
Cleaning images build artifacts ... done
Cleaning make-support build artifacts ... done
Cleaning test-make build artifacts ... done
Cleaning bundles build artifacts ... done
Cleaning buildjdk build artifacts ... done
Cleaned all build artifacts.
Finished building target 'clean' in configuration 'linux-x86_64-server-release'

$ make CONF=linux-x86_64-server-release
Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling 1 files for BUILD_TOOLS_HOTSPOT
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
...
Compiling 47 files for jdk.jpackage
Compiling 8 files for jdk.unsupported.desktop
In member function 'void G1GCPhaseTimes::log_phase(WorkerDataArray<double>*, uint, outputStream*, bool) const',
    inlined from 'void G1GCPhaseTimes::trace_phase(WorkerDataArray<double>*, bool, uint) const' at /home/mgkwill/src/git/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:355:14:

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

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

From mgkwill at openjdk.java.net  Fri May  7 22:30:51 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 7 May 2021 22:30:51 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <gDTZPBzVO5hHGEujwIKCjerX0bVfDC3tU1UZOSHM4fI=.b1d448d7-cf61-46f0-8a9a-3f663fe7381b@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

FYI: Upon reverting **_8214237: Join parallel phases post evacuation_** #3811 my local build works again. I'm not sure why I'm seeing the issue and not others. Not sure if this is an intermittent/obscure bug or weird tooling issue.

On openjdk/jdk master:

$ git revert 14f0afe8118092be530aac0c4cc5d1d5d4fe982a
Removing src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp
Removing src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
[test_fix 3dd72600fbd] Revert "8214237: Join parallel phases post evacuation"
 26 files changed, 801 insertions(+), 1081 deletions(-)
 delete mode 100644 src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
 delete mode 100644 src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp
$ make clean all CONF=linux-x86_64-server-release
Building targets 'clean all' in configuration 'linux-x86_64-server-release'
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
...
Creating images/test/micro/benchmarks.jar
Creating interim jimage
Compiling 1 files for CLASSLIST_JAR
Creating support/classlist.jar
Creating jdk.jlink.jmod
Creating java.base.jmod
Creating jdk image
Creating CDS archive for jdk image
Creating CDS-NOCOOPS archive for jdk image
Stopping sjavac server
Finished building targets 'clean all' in configuration 'linux-x86_64-server-release'

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

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

From mgkwill at openjdk.java.net  Fri May  7 22:30:53 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 7 May 2021 22:30:53 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <gDTZPBzVO5hHGEujwIKCjerX0bVfDC3tU1UZOSHM4fI=.b1d448d7-cf61-46f0-8a9a-3f663fe7381b@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <gDTZPBzVO5hHGEujwIKCjerX0bVfDC3tU1UZOSHM4fI=.b1d448d7-cf61-46f0-8a9a-3f663fe7381b@github.com>
Message-ID: <bKSch36QSlwk-gnPx95Jb0DS0YFJsJw5t_Oukau6s3s=.49f48e40-d21b-47dd-b8c8-4e110fad9f83@github.com>

On Fri, 7 May 2021 21:56:11 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

> FYI: Upon reverting **_8214237: Join parallel phases post evacuation_** #3811 my local build works again. I'm not sure why I'm seeing the issue and not others. Not sure if this is an intermittent/obscure bug or weird tooling issue.
> 
> On openjdk/jdk master:
> 
> ```
> $ git revert 14f0afe8118092be530aac0c4cc5d1d5d4fe982a
> Removing src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp
> Removing src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
> [test_fix 3dd72600fbd] Revert "8214237: Join parallel phases post evacuation"
>  26 files changed, 801 insertions(+), 1081 deletions(-)
>  delete mode 100644 src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
>  delete mode 100644 src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp
> $ make clean all CONF=linux-x86_64-server-release
> Building targets 'clean all' in configuration 'linux-x86_64-server-release'
> Cleaning hotspot build artifacts ... done
> Cleaning jdk build artifacts ... done
> ...
> Creating images/test/micro/benchmarks.jar
> Creating interim jimage
> Compiling 1 files for CLASSLIST_JAR
> Creating support/classlist.jar
> Creating jdk.jlink.jmod
> Creating java.base.jmod
> Creating jdk image
> Creating CDS archive for jdk image
> Creating CDS-NOCOOPS archive for jdk image
> Stopping sjavac server
> Finished building targets 'clean all' in configuration 'linux-x86_64-server-release'
> ```

Filed https://bugs.openjdk.java.net/browse/JDK-8266773 in case this an obscure bug.

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

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

From yyang at openjdk.java.net  Sat May  8 03:00:14 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 03:00:14 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v9]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <BtR2gR2JzdslWm0v3dpLqKoJ3HPGcpGLtaF2iE70Igw=.84418518-d27c-47b2-a148-f764aefdd3eb@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

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

  x86_32 fails

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/f996c99f..307d7a10

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

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

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

From yyang at openjdk.java.net  Sat May  8 05:36:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 05:36:17 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
 <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>
Message-ID: <GZGUdR618n7EWnif8odL3pBY55IwmneeqHXSXu53s2k=.2b0261af-5815-4e3e-ba2f-f03b4d44d00b@github.com>

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Looks like now the test fails in the pre-submit tests?

Hi Igor,

Can you take a look at the latest version? Now it passes all pre-submit tests.

Best Regards,
Yang

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

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

From yyang at openjdk.java.net  Sat May  8 05:36:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 05:36:17 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
 <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
Message-ID: <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>

On Fri, 30 Apr 2021 17:30:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic. Very good!

Hi Paul,

Thank you for noticing this PR.
> It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic.
Yes, this patch adds C1 intrinsic supports for checkIndex, I will replace all variants of checkIndex with Objects.checkIndex in follow-up PRs.

It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.

> Very good!
Thank you Paul~

Best Regards,
Yang

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

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

From stuefe at openjdk.java.net  Sat May  8 06:36:06 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 8 May 2021 06:36:06 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <-u39zUYUkTGaDdiGLZOqym7B7oeSO4uHGhmPWKTMo3s=.42761688-cfc5-4265-aec8-21906371a998@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

The build warning makes not much sense to me, and is not reproducable. None of the callers of log_phase hands in any indentation > 4. 

However, that indentation code is a bit inelegant anyway. @mgkwill : can you test this patch, does this fix your build? : https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/3934.diff

This uses outputStream::sp() to print indentation. Note that in places where that's not convenient, and I want to go via format string instead I usually do something like this:

static const char* spaces = "                        ...   ";
..
out->print("%.*s", indentation, spaces);


That way you don't have to keep a const indentation string for every level. If you miss the assert, it could be squeezed in too.

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

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

From aph at openjdk.java.net  Sat May  8 08:59:19 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 8 May 2021 08:59:19 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64
In-Reply-To: <fhRKGqqXcUQ6yVL3Kh623Pe-hwjeaSz-Ol57plriUHs=.566b15a9-d9d6-4f79-9913-3abe5a96d51b@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
 <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
 <FWojWvyXJR47qji7jS63POPC9slszN47yH70KB_fTf8=.750f5a6f-a0f8-466d-a0c1-8efabf322b5b@github.com>
 <fhRKGqqXcUQ6yVL3Kh623Pe-hwjeaSz-Ol57plriUHs=.566b15a9-d9d6-4f79-9913-3abe5a96d51b@github.com>
Message-ID: <0A3WWPkNU0nlPYeUfJ7BJkIVZASDqf6KzJPbrJ92xvI=.c0abd4fd-a002-41e0-bc9b-808f567083ca@github.com>

On Fri, 7 May 2021 15:05:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Unfortunately, tmp1 == noreg here.
>
> so, this is better alternative?
>     `Label lrb;`
>     `__ tbnz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, lrb);`
>     `__ tbnz(rscratch2, ShenandoahHeap::WEAK_ROOTS_BITPOS, lrb);`
>     `__ b(heap_stable);`
>     `__ bind(lrb);`

How about

 // Check for heap stability                                                                                                                                                                
  if (is_strong) {
    __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, heap_stable);
  } else {
    label lrb;
    __ tbnz(rscratch2, ShenandoahHeap::WEAK_ROOTS_BITPOS, lrb);
    __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, heap_stable);
    __ bind(lrb);
  }

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

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

From aph at openjdk.java.net  Sat May  8 09:20:12 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 8 May 2021 09:20:12 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
Message-ID: <FQFtXo8OgMcw1Z2rKyezbys7cBKD5zML_unhQVXBBa0=.d9f044e4-f253-4b4e-9fbb-67cfafb99b9f@github.com>

On Fri, 7 May 2021 15:38:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
> 
> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.

src/hotspot/share/prims/universalNativeInvoker.cpp line 35:

> 33: void ProgrammableInvoker::invoke_native(Stub stub, address buff, JavaThread* thread) {
> 34:   ThreadToNativeFromVM ttnfvm(thread);
> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread));

I think we need a comment here, not just in the bug report. if this confused you, it'll surely be enough to confuse a maintainer. Some think like this, perhaps?

`"We need WXExec because we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache. See JDK-8265292."`

I'm also wondering if it would be better to enable writes in the methods that actually write to the nmethod, WDYT?

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

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

From zgu at openjdk.java.net  Sat May  8 15:22:30 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Sat, 8 May 2021 15:22:30 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64 [v2]
In-Reply-To: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
Message-ID: <SSeIRCcO-q3OgoUtR2bP-MxryYgi0C9fwUab7zEP9lE=.59e2e5f8-471e-4415-9465-5fd80715c703@github.com>

> JDK-8263427 missed corresponding changes for aarch64.
> 
> LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Macosx/AArch64
> - [ ] hotspot_gc_shenandoah on Linux 64/AArch64

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

  v2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3902/files
  - new: https://git.openjdk.java.net/jdk/pull/3902/files/fea11bc4..4bb453b9

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

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

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

From zgu at openjdk.java.net  Sat May  8 15:22:32 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Sat, 8 May 2021 15:22:32 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64 [v2]
In-Reply-To: <0A3WWPkNU0nlPYeUfJ7BJkIVZASDqf6KzJPbrJ92xvI=.c0abd4fd-a002-41e0-bc9b-808f567083ca@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
 <KlAW3tExd6Px1Fhfi6fzPz85VItw35q8amZaizIZvpU=.0f9fde05-22ca-4907-8cad-39587a48739c@github.com>
 <FWojWvyXJR47qji7jS63POPC9slszN47yH70KB_fTf8=.750f5a6f-a0f8-466d-a0c1-8efabf322b5b@github.com>
 <fhRKGqqXcUQ6yVL3Kh623Pe-hwjeaSz-Ol57plriUHs=.566b15a9-d9d6-4f79-9913-3abe5a96d51b@github.com>
 <0A3WWPkNU0nlPYeUfJ7BJkIVZASDqf6KzJPbrJ92xvI=.c0abd4fd-a002-41e0-bc9b-808f567083ca@github.com>
Message-ID: <GR7pgoDRdzs6ZCCwiejdwwyFvMWctb16CHxa53njdEM=.d07b6737-06f5-4d53-b6d8-5bdd87f42ae0@github.com>

On Sat, 8 May 2021 08:55:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> so, this is better alternative?
>>     `Label lrb;`
>>     `__ tbnz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, lrb);`
>>     `__ tbnz(rscratch2, ShenandoahHeap::WEAK_ROOTS_BITPOS, lrb);`
>>     `__ b(heap_stable);`
>>     `__ bind(lrb);`
>
> How about
> 
>  // Check for heap stability                                                                                                                                                                
>   if (is_strong) {
>     __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, heap_stable);
>   } else {
>     label lrb;
>     __ tbnz(rscratch2, ShenandoahHeap::WEAK_ROOTS_BITPOS, lrb);
>     __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, heap_stable);
>     __ bind(lrb);
>   }

Yep, much better. Thanks.

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

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

From psandoz at openjdk.java.net  Sat May  8 15:56:05 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Sat, 8 May 2021 15:56:05 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
 <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
 <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>
Message-ID: <bW8wQgYpWIGFXjafFn2ahr6-trK7uQa5xGxOdJucUsc=.ed4916ef-1c09-4f8f-bd62-274b8337456a@github.com>

On Sat, 8 May 2021 05:32:00 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.
>

It might be possible to directly use `Preconditions.checkIndex` for such purposes, its package is non-exported but public for reuse within `java.base`. It's used in `VarHandle` `byte` array access code, see [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L117).

I would caution against adding a public API to support this. The work in  `Preconditions` was the basis for a public API, but it proved complicated. I am glad we did not expose that, it would of made exposing the long accepting `Objects.checkIndex` methods more difficult.

Paul.

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

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

From ayang at openjdk.java.net  Sat May  8 19:45:56 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sat, 8 May 2021 19:45:56 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <Bxy1cQWv1um9l2ZcnaA-iI8ZY7oQnR3uEvF1zSU7ioQ=.7f230148-23d3-4f9d-b575-bef643cbb0ba@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
 <Bxy1cQWv1um9l2ZcnaA-iI8ZY7oQnR3uEvF1zSU7ioQ=.7f230148-23d3-4f9d-b575-bef643cbb0ba@github.com>
Message-ID: <rrc7WmyrWaHKZ6nOucZcud54JEmGWjMXvdcco3iTpPQ=.3455038d-87ff-4525-99b6-369f55a92032@github.com>

On Fri, 7 May 2021 17:26:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Adding the assertion, and fixing a benign violation.
>> 
>> Test: tier1-7; no violation of this assertion.
>
> src/hotspot/share/gc/g1/g1Allocator.cpp line 460:
> 
>> 458:   // chunk if we don't yet cross the boundary, but the remainder would be too
>> 459:   // small to fill.
>> 460:   HeapWord* new_top = old_top + word_size;
> 
> Pre-existing but related to the change - What, if anything, prevents the calculation of new_top from overflowing or detects that happened.  The usual way we do such calculations safely involves first checking that `(_max - old_top) <= word_size` or something similar.  I don't see anything to prevent that, and if nothing does then the various checks and calculations involving new_top are suspect.

Thanks for pointing this out. A fix at https://github.com/openjdk/jdk/pull/3936

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

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

From aph at openjdk.java.net  Sun May  9 09:05:02 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 9 May 2021 09:05:02 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <FQFtXo8OgMcw1Z2rKyezbys7cBKD5zML_unhQVXBBa0=.d9f044e4-f253-4b4e-9fbb-67cfafb99b9f@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
 <FQFtXo8OgMcw1Z2rKyezbys7cBKD5zML_unhQVXBBa0=.d9f044e4-f253-4b4e-9fbb-67cfafb99b9f@github.com>
Message-ID: <AFQ7ghA-D9kmMyph4MYynW2Qb_57d4uCwbA1q2WrGIo=.c5906aee-3c85-43a7-bd69-f85ab953b2a7@github.com>

On Sat, 8 May 2021 09:16:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
>> 
>> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.
>
> src/hotspot/share/prims/universalNativeInvoker.cpp line 35:
> 
>> 33: void ProgrammableInvoker::invoke_native(Stub stub, address buff, JavaThread* thread) {
>> 34:   ThreadToNativeFromVM ttnfvm(thread);
>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread));
> 
> I think we need a comment here, not just in the bug report. if this confused you, it'll surely be enough to confuse a maintainer. Some think like this, perhaps?
> 
> `"We need WXExec because we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache. See JDK-8265292."`
> 
> I'm also wondering if it would be better to enable writes in the methods that actually write to the nmethod, WDYT?

And incidentally, this seems to be rather error prone. Wouldn't it be simpler to check W^X status in all of the nmethod accessors, and change it when actually required, rather than hoping that it's already in the correct state?

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

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

From coleenp at openjdk.java.net  Sun May  9 22:54:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Sun, 9 May 2021 22:54:08 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

I started out thinking that this was too big and should be broken up but then the change is pretty simple to review and mostly mechanical.  So ignore my comments to break it up.  I think it's fine.  Hitting "approve" even though it's a draft.

src/hotspot/share/cds/archiveBuilder.cpp line 903:

> 901: 
> 902:   static void write_klass(Klass* k, address runtime_dest, const char* type_name, int bytes, Thread* THREAD) {
> 903:     ResourceMark rm(THREAD);

This change seems like it could be an independent check in because all you did was change the name of the parameter here, ie doesn't depend on on THREAD being a JavaThread.

src/hotspot/share/cds/dynamicArchive.cpp line 172:

> 170:   _header = mapinfo->dynamic_header();
> 171: 
> 172:   Thread* THREAD = Thread::current();

Unused?  Looks like you could also remove these in a trivial pre-commit.

src/hotspot/share/classfile/classLoader.cpp line 1077:

> 1075: 
> 1076: // Search either the patch-module or exploded build entries for class.
> 1077: ClassFileStream* ClassLoader::search_module_entries(JavaThread* current,

I wonder if these CDS and classLoader.hpp/cpp changes can be done first?  Just change the caller to pass ->as_Java_thread() until TRAPS is changed.

src/hotspot/share/runtime/sharedRuntime.cpp line 1197:

> 1195: 
> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
> 1197:   JavaThread* current = THREAD;

I think these look strange, especially the ones
JavaThread* thread = THREAD;
but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.

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

Marked as reviewed by coleenp (Reviewer).

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

From dholmes at openjdk.java.net  Sun May  9 22:54:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 9 May 2021 22:54:07 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
Message-ID: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>

Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done that
  pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:

- declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
- methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
- Manifestations of Thread::current() become JavaThread::current()
- THREAD->as_Java_thread() becomes just THREAD
- THREAD->is_Java_thread() is reworked so that THREAD is "current"

There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.

Testing:
 - tiers 1-8 on Linux-x64
 - all builds in tiers 1-4
 - tiers 1-3 on all platforms

Thanks,
David

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

Commit messages:
 - Merge
 - 8252685: APIs that require JavaThread should take JavaThread arguments

Changes: https://git.openjdk.java.net/jdk/pull/3877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252685
  Stats: 537 lines in 121 files changed: 14 ins; 30 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877

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

From dholmes at openjdk.java.net  Sun May  9 22:54:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 9 May 2021 22:54:08 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <rdpjS7yRdsrtbdGEtOLGVp_EMojwCYqMzdyBtOqPAaE=.c874d813-d4bd-4e12-93f0-bf0ba8d88920@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

Thanks for the pre-review comments Coleen! I started responding to your various comments then realized they were the ones about breaking things up that you said I could now ignore :)

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

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

From dholmes at openjdk.java.net  Sun May  9 22:54:10 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 9 May 2021 22:54:10 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>
Message-ID: <r4U5VJq6BcO553mYLANBvfzyvvfPbbMIMyfe9xnWxpE=.b4ffb154-53ba-44d0-9cc8-1075bc469099@github.com>

On Sat, 8 May 2021 13:06:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> src/hotspot/share/cds/archiveBuilder.cpp line 903:
> 
>> 901: 
>> 902:   static void write_klass(Klass* k, address runtime_dest, const char* type_name, int bytes, Thread* THREAD) {
>> 903:     ResourceMark rm(THREAD);
> 
> This change seems like it could be an independent check in because all you did was change the name of the parameter here, ie doesn't depend on on THREAD being a JavaThread.

Under these changes THREAD is always a JavaThread so I either need to change the type here (which would be wrong) or else change the name, because it doesn't actually relate to TRAPS/exceptions.  As this change touches a lot of files keeping it merged it time consuming so I'd prefer not to have to split out anything further at this stage. Thanks.

> src/hotspot/share/cds/dynamicArchive.cpp line 172:
> 
>> 170:   _header = mapinfo->dynamic_header();
>> 171: 
>> 172:   Thread* THREAD = Thread::current();
> 
> Unused?  Looks like you could also remove these in a trivial pre-commit.

Yes unused. Again trying to avoid further delays. Also I think this code just went through an undo and will soon be redone, in which case if it gets integrated first I'll try to get this cleaned up. Thanks.

> src/hotspot/share/runtime/sharedRuntime.cpp line 1197:
> 
>> 1195: 
>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
>> 1197:   JavaThread* current = THREAD;
> 
> I think these look strange, especially the ones
> JavaThread* thread = THREAD;
> but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.

They are the inverse of the

JavaThread* THREAD = current; // For exception macro use.

due to the general trend to not use THREAD for non-exception related code except in some trivial cases.

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

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

From dholmes at openjdk.java.net  Mon May 10 05:19:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 10 May 2021 05:19:56 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
Message-ID: <Fvo-PVERp2vtzkFA6GFmGpxXOPI68Gh5Z1hvycGDo_o=.de4cbb77-9da8-4c03-a614-3d647e24c759@github.com>

On Fri, 7 May 2021 15:38:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
> 
> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.

If this fixes the problem - great, approved.

But this just highlights the limited understanding around W^X and thread states IMO.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Mon May 10 05:47:20 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 10 May 2021 05:47:20 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
Message-ID: <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>

On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor adjustment

Hi,

Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case? And what is the impact on other cases as we're now increasing the overhead of the hash computation.

Thanks,
David

test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57:

> 55:         byte[] buf = new byte[100];
> 56:         int size = writeClass(buf, "MH$$");
> 57:         Class<?> cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null);

Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API?

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

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

From dongbo at openjdk.java.net  Mon May 10 05:55:59 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 10 May 2021 05:55:59 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
Message-ID: <L1nxE0TrmazPCw0-HwkehQVMpRguDpmSkNu4kNUaIIk=.2bf3d9b3-5fcc-4161-b068-63d9b918157c@github.com>

On Mon, 26 Apr 2021 11:16:00 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
>> 
>> 
>> ## reduce_add2I, before
>> mov    w10, v19.s[0]
>> mov    w2, v19.s[1]
>> add    w10, w0, w10
>> add    w10, w10, w2
>> ## reduce_add2I, optimized
>> addp   v23.2s, v24.2s, v24.2s
>> mov    w10, v23.s[0]
>> add    w10, w10, w2
>> 
>> ## reduce_max2I, before
>> dup    v16.2d, v23.d[0]
>> sminv  s16, v16.4s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> ## reduce_max2I, optimized
>> sminp  v16.2s, v23.2s, v23.2s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> 
>> 
>> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
>> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
>> 
>> 
>> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
>> # optimized
>> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
>> # default
>> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
>> 
>> 
>> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
>> 
>> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assembler tests for smaxp/sminp

PING? Any comments/suggestions are appreciated.
Although this has been reviewed by Ningsheng, we still need help from reviewers here.

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

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

From dholmes at openjdk.java.net  Mon May 10 06:05:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 10 May 2021 06:05:25 GMT
Subject: RFR: 8252530: Fix inconsistencies in hotspot whitebox
In-Reply-To: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
References: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
Message-ID: <QbFciPCwYJ9-F4FXbb9eCQUqOmVbo68ljXF8nFLK8ZY=.6f119302-5ecd-44a6-a82e-31d8899029ba@github.com>

On Fri, 7 May 2021 18:44:59 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Replace the runtime check and remove the "InVmBuild" suffix as described in the bug.

Hi Philippe,

This all seems fine to me!

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From xliu at openjdk.java.net  Mon May 10 08:02:22 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 10 May 2021 08:02:22 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
Message-ID: <jVm1Qhu1ncfHKBOEe6NIg0b6tt-KyoN4OaouIrXguws=.1b1e5048-b765-4ce8-8a9b-bb54f7a23396@github.com>

On Thu, 6 May 2021 15:25:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.
>
> src/hotspot/share/logging/logAsyncFlusher.hpp line 107:
> 
>> 105:   void writeback();
>> 106: 
>> 107:   // two AsyncLogMessage are equal if both _output and _message are same.
> 
> Decorators don't matter here?

This equals() is a placeholder, which is required by LinkedListImpl. 
I create a new PR to loose this constraint. if it works, I will remove this equals() member function.
https://github.com/openjdk/jdk/pull/3944

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

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

From tschatzl at openjdk.java.net  Mon May 10 09:10:58 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 10 May 2021 09:10:58 GMT
Subject: RFR: 8266637: CHT: Add insert_and_get method
In-Reply-To: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
References: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
Message-ID: <WB63CsVG_kJesDoclESB1Cm61muSDXPSsVG0_CzPmyY=.81f68875-1f4a-4251-8f08-5d6fccf54d7d@github.com>

On Fri, 7 May 2021 09:27:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to add an `insert_get` method to the CHT.  The method combines `insert()` and `get()` methods to decrease the amount of global synchronization needed for `get()` calls after an `insert` call. 
> 
> Testing: tier1-3

Lgtm, but wait for a runtime team reviewer.

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

Marked as reviewed by tschatzl (Reviewer).

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

From tschatzl at openjdk.java.net  Mon May 10 09:15:00 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 10 May 2021 09:15:00 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
Message-ID: <XreGGH7Tk0cotKsHLVM1VQJz4niwNHIomhcDetWkca0=.8b322a5b-e610-4e7b-8299-78aa16332945@github.com>

On Thu, 6 May 2021 14:02:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Adding the assertion, and fixing a benign violation.
> 
> Test: tier1-7; no violation of this assertion.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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

From tschatzl at openjdk.java.net  Mon May 10 09:15:01 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 10 May 2021 09:15:01 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <rrc7WmyrWaHKZ6nOucZcud54JEmGWjMXvdcco3iTpPQ=.3455038d-87ff-4525-99b6-369f55a92032@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
 <Bxy1cQWv1um9l2ZcnaA-iI8ZY7oQnR3uEvF1zSU7ioQ=.7f230148-23d3-4f9d-b575-bef643cbb0ba@github.com>
 <rrc7WmyrWaHKZ6nOucZcud54JEmGWjMXvdcco3iTpPQ=.3455038d-87ff-4525-99b6-369f55a92032@github.com>
Message-ID: <fBBOjcDp1VyQvUoyNNtl3ziNKp0ehq1RyzeSa6UihPY=.832d1198-01dd-40ca-90a5-8c7e6cf9d687@github.com>

On Sat, 8 May 2021 19:43:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Allocator.cpp line 460:
>> 
>>> 458:   // chunk if we don't yet cross the boundary, but the remainder would be too
>>> 459:   // small to fill.
>>> 460:   HeapWord* new_top = old_top + word_size;
>> 
>> Pre-existing but related to the change - What, if anything, prevents the calculation of new_top from overflowing or detects that happened.  The usual way we do such calculations safely involves first checking that `(_max - old_top) <= word_size` or something similar.  I don't see anything to prevent that, and if nothing does then the various checks and calculations involving new_top are suspect.
>
> Thanks for pointing this out. A fix at https://github.com/openjdk/jdk/pull/3936

I think the code is "good" but should be fixed - the `word_size` values are never user controlled afaict.

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

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

From aph at redhat.com  Mon May 10 09:46:10 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 10 May 2021 10:46:10 +0100
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <Fvo-PVERp2vtzkFA6GFmGpxXOPI68Gh5Z1hvycGDo_o=.de4cbb77-9da8-4c03-a614-3d647e24c759@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
 <Fvo-PVERp2vtzkFA6GFmGpxXOPI68Gh5Z1hvycGDo_o=.de4cbb77-9da8-4c03-a614-3d647e24c759@github.com>
Message-ID: <05d6bc80-f34d-c128-33af-f5299ac6da40@redhat.com>

On 5/10/21 6:19 AM, David Holmes wrote:
> On Fri, 7 May 2021 15:38:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:
> 
>> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
>>
>> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.
> 
> If this fixes the problem - great, approved.
> 
> But this just highlights the limited understanding around W^X and thread states IMO.

Yes, that's what I was getting at. This looks to me like an instance of
the Temporal Coupling design smell.


From aph at openjdk.java.net  Mon May 10 09:51:22 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 10 May 2021 09:51:22 GMT
Subject: RFR: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64 [v2]
In-Reply-To: <SSeIRCcO-q3OgoUtR2bP-MxryYgi0C9fwUab7zEP9lE=.59e2e5f8-471e-4415-9465-5fd80715c703@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
 <SSeIRCcO-q3OgoUtR2bP-MxryYgi0C9fwUab7zEP9lE=.59e2e5f8-471e-4415-9465-5fd80715c703@github.com>
Message-ID: <uE9Sk60ZRPaVSQIdQ_WpbpMHHHQvlAVTw1FOnp2BT3A=.acca6921-a885-4f5e-b67e-d015f89d44a7@github.com>

On Sat, 8 May 2021 15:22:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8263427 missed corresponding changes for aarch64.
>> 
>> LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah on Macosx/AArch64
>> - [ ] hotspot_gc_shenandoah on Linux 64/AArch64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   v2

Marked as reviewed by aph (Reviewer).

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

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

From coleenp at openjdk.java.net  Mon May 10 12:35:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 10 May 2021 12:35:52 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <r4U5VJq6BcO553mYLANBvfzyvvfPbbMIMyfe9xnWxpE=.b4ffb154-53ba-44d0-9cc8-1075bc469099@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>
 <r4U5VJq6BcO553mYLANBvfzyvvfPbbMIMyfe9xnWxpE=.b4ffb154-53ba-44d0-9cc8-1075bc469099@github.com>
Message-ID: <YMLMNWMtkqxjJrcjMlNMJ8dbVr28U9FHvpoJauZzy9M=.be2936ab-0535-4ea4-91c1-b337cb56f223@github.com>

On Sun, 9 May 2021 22:42:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 1197:
>> 
>>> 1195: 
>>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
>>> 1197:   JavaThread* current = THREAD;
>> 
>> I think these look strange, especially the ones
>> JavaThread* thread = THREAD;
>> but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.
>
> They are the inverse of the
> 
> JavaThread* THREAD = current; // For exception macro use.
> 
> due to the general trend to not use THREAD for non-exception related code except in some trivial cases.

I know what they are.  I think if we already have a THREAD then there's no point having another thread or current variable and it's noisy and confusing, ie. we *know* that THREAD is the current thread by definition and 'current' seems to suggest by name but no guarantee of that, and 'thread' is just generic and means nothing.  I don't think there should be another variable introduced for Handles and ResourceMarks.  Using another variable for last_frame and such might make some sense.  Anyway, my definition of "trivial" cases might be more broad than yours.
It's not for this change, though, this change is fine, even though I think these extra declarations should be removed at some later date if the code changes for some other reason.

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

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

From xliu at openjdk.java.net  Mon May 10 13:35:35 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 10 May 2021 13:35:35 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
Message-ID: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>

Devirtualize find, find_node and remove. This patch make both LinkedListImpl
and SortedLinkedList more generic. If the client doesn't use those member functions,
it's not necessary to define equals() for the user-defined class E.

Remove those 3 member functions from the pure interface LinkedList. subclasses
implement them using regular member functions.

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

Commit messages:
 - 8266789: devirtualize find_node and remove of LinkedList

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

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

From xliu at openjdk.java.net  Mon May 10 13:35:36 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 10 May 2021 13:35:36 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <VdC5V3luSljGTHTyJb17YWuZMMADwfOZvFRAcsDs9TM=.eb436307-7722-4805-93a7-cfbdf1258106@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

src/hotspot/share/utilities/linkedlist.hpp line 405:

> 403:   // unhide base class's the overloaded member function
> 404:   // remove(LinkedListNode<E>* node), which has no reference.
> 405:   // remove the using statement we delete boo remove(LinkedListNode<E>* node).

Should be bool* remove here. 
actually, bool remove(LinkedListNode<E>* node) is a dead member function. no reference at all. 
I am not sure I should remove it or keep it.

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

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

From zgu at openjdk.java.net  Mon May 10 13:50:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 10 May 2021 13:50:53 GMT
Subject: RFR: 8266813: Use shorter instruction sequence for checking if
 marking in progress
Message-ID: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>

ShenandoahBarrierSetAssembler::generate_c1_pre_barrier_runtime_stub() on aarch64, we can replace ld, tst, br instruction sequence with a single tbz.

Test:
- [x] hotspot_gc_shenandoah on Linux aarch64

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

Commit messages:
 - v1

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

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

From iwalulya at openjdk.java.net  Mon May 10 14:15:36 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 10 May 2021 14:15:36 GMT
Subject: RFR: 8233378: CHT: Fast reset
Message-ID: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>

Hi all,

Please review this change to add a dedicated method that just resets the internal table (optionally setting it to a new size) without going through new/delete of the CHT. Currently, the CHT destructor calls Value::destroy_node() on every element in the table which may be very slow for some use-cases.

Testing: tier 1-3 (Linux, Windows).

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

Commit messages:
 - Add cht_reset method

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

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

From aph at openjdk.java.net  Mon May 10 14:32:19 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 10 May 2021 14:32:19 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
Message-ID: <rRTo1d5f2YmqJqS0LLvbpEYkbAAW4Ixdn61xjS1t61M=.a3795f9c-77af-43a6-af0a-92ff8a73b742@github.com>

On Mon, 26 Apr 2021 11:16:00 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
>> 
>> 
>> ## reduce_add2I, before
>> mov    w10, v19.s[0]
>> mov    w2, v19.s[1]
>> add    w10, w0, w10
>> add    w10, w10, w2
>> ## reduce_add2I, optimized
>> addp   v23.2s, v24.2s, v24.2s
>> mov    w10, v23.s[0]
>> add    w10, w10, w2
>> 
>> ## reduce_max2I, before
>> dup    v16.2d, v23.d[0]
>> sminv  s16, v16.4s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> ## reduce_max2I, optimized
>> sminp  v16.2s, v23.2s, v23.2s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> 
>> 
>> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
>> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
>> 
>> 
>> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
>> # optimized
>> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
>> # default
>> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
>> 
>> 
>> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
>> 
>> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assembler tests for smaxp/sminp

Looking now. I can't quite understand how to run tests from panama-vector on JDK head. If the JMH test is relevant to JDK, not just panama-vector, why not add it to JDK?

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

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

From psandoz at openjdk.java.net  Mon May 10 15:58:11 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 15:58:11 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <rRTo1d5f2YmqJqS0LLvbpEYkbAAW4Ixdn61xjS1t61M=.a3795f9c-77af-43a6-af0a-92ff8a73b742@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
 <rRTo1d5f2YmqJqS0LLvbpEYkbAAW4Ixdn61xjS1t61M=.a3795f9c-77af-43a6-af0a-92ff8a73b742@github.com>
Message-ID: <BwJj4b0EKL6I5AZXsv6wge1FT2QgMy66m1Wi-9Wp0Mo=.6a368524-058f-4abe-820a-fd4d08610e51@github.com>

On Mon, 10 May 2021 14:29:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add assembler tests for smaxp/sminp
>
> Looking now. I can't quite understand how to run tests from panama-vector on JDK head. If the JMH test is relevant to JDK, not just panama-vector, why not add it to JDK?

@theRealAph we are still working out how best to bring the vector performance tests over to the `test/micro` area of mainline. (Some preliminary work is [here](https://github.com/openjdk/panama-vector/pull/77)). The perf tests in the `panama-vector` are under a maven project and it should be possible to build/run that project with a mainline build of the JDK (the tests should be compatible).

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

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

From shade at openjdk.java.net  Mon May 10 16:38:19 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 10 May 2021 16:38:19 GMT
Subject: RFR: 8266813: Use shorter instruction sequence for checking if
 marking in progress
In-Reply-To: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>
References: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>
Message-ID: <STs8VbOh2ZO62QowWj96gKk-AqmylqNwPQWHhe6lozg=.38861f07-d639-42dd-ae42-487a36a6ece2@github.com>

On Mon, 10 May 2021 13:21:44 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahBarrierSetAssembler::generate_c1_pre_barrier_runtime_stub() on aarch64, we can replace ld, tst, br instruction sequence with a single tbz.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux aarch64

This looks fine to me.

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

Marked as reviewed by shade (Reviewer).

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

From ddong at openjdk.java.net  Mon May 10 17:43:55 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Mon, 10 May 2021 17:43:55 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
Message-ID: <Por8B_2H2aXaFmnnhzpq_wqAEf0MNzb6OjWY5dbSz2Q=.2918beff-cb20-469a-a710-3aa54f4e73ea@github.com>

On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor adjustment

Hi David,

Thanks for your comment!

> Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case?

Actually, the performance problem we noticed occurred in jdk 11u, here's a simplified piece of code:


import java.lang.invoke.*;
import java.util.*;

class Test {
    public static void main(String[] args) throws Throwable{
        MethodType mt = MethodType.methodType(void.class);

        List<MethodHandle> mhs = new ArrayList<>();
        for (int i = 0; i < 2000; i++) {
            // In practice, it will point to different methods
            mhs.add(MethodHandles.lookup().findVirtual(Test.class, "call",
                                                       MethodType.methodType(void.class))
                                 .bindTo(new Test()));
        }

        for (int i = 0; i < 128; i++) {
            for (MethodHandle mh : mhs) {
                mh.invokeExact();
            }
        }
    }

    void call() {}
}


Run: `java -Xlog:membername+table=debug Test`, and we can see that all of the LambdaForm$MH use a same slot.

[0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254840.invoke(Ljava/lang/Object;)V index 219
[0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254c40.invoke(Ljava/lang/Object;)V index 219
[0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255040.invoke(Ljava/lang/Object;)V index 219
[0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255440.invoke(Ljava/lang/Object;)V index 219



This problem doesn't exist in jdk upstream because of the name-mangling mechanism for hidden class(ClassFileParser::mangle_hidden_class_name).

However, if the user creates many classes with the same name by different classloaders, the performance problems will still appear, although I also think that the general user will not implement the code in this way.

My plan is to fix this problem in the upstream and then backport it to JDK 11, what do you think?

> And what is the impact on other cases as we're now increasing the overhead of the hash computation.

I think the overhead is negligible, here is a benchmark based on ResolvedMethodTableHash.java:


import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;

@State(Scope.Benchmark)
public class MyBenchmark extends ClassLoader {

    // Produce a class file with the given name and a single method:
    //     public static native void m();
    private int writeClass(byte[] buf, String className) {
       ... same as ResolvedMethodTableHash.java
    }

    private List<Class<?>> classes = new ArrayList<>();
    private Random r = new Random();

    @Setup
    public void prepare() throws Exception {
        for (int i = 0; i < 5000; i ++) {
            byte[] buf = new byte[100];
            int size = writeClass(buf, "MH$" + i);
            classes.add(defineClass(null, buf, 0, size));
        }
    }


    @Benchmark
    @Fork(value=1)
    @Warmup(iterations = 5, time = 1)
    public void test(Blackhole bh) throws Exception {
        MethodHandle mh = MethodHandles.publicLookup().findStatic(classes.get(r.nextInt(5000)),
                                                                  "m", MethodType.methodType(void.class));
        if (mh == null) {
            throw new RuntimeException();
        }
    }
}


on linux x86_64,

result with the patch:

Result: 904126.215 ?(99.9%) 26603.356 ops/s [Average]
  Statistics: (min, avg, max) = (852079.715, 904126.215, 927791.630), stdev = 30636.464
  Confidence interval (99.9%): [877522.859, 930729.571]

Benchmark                Mode  Samples       Score  Score error  Units
o.s.MyBenchmark.test    thrpt       20  904126.215    26603.356  ops/s


result without the patch:

Result: 883669.014 ?(99.9%) 26455.778 ops/s [Average]
  Statistics: (min, avg, max) = (830830.551, 883669.014, 906978.220), stdev = 30466.514
  Confidence interval (99.9%): [857213.236, 910124.792]

Benchmark                Mode  Samples       Score  Score error  Units
o.s.MyBenchmark.test    thrpt       20  883669.014    26455.778  ops/s

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

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

From ddong at openjdk.java.net  Mon May 10 17:43:56 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Mon, 10 May 2021 17:43:56 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
Message-ID: <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>

On Mon, 10 May 2021 05:40:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor adjustment
>
> test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57:
> 
>> 55:         byte[] buf = new byte[100];
>> 56:         int size = writeClass(buf, "MH$$");
>> 57:         Class<?> cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null);
> 
> Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API?

Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose.

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

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

From mcimadamore at openjdk.java.net  Mon May 10 17:45:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 17:45:24 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v14]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <XpUq2tbuPwusth8QnstMpG2Las74JE7-a7cTpnNc4_0=.2ad132a4-a8e7-4f90-8a77-eefc6b2196f3@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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

  Remove redundant checks for --enable-native-access

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/1ce6366a..3aaeb09f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=12-13

  Stats: 64 lines in 7 files changed: 0 ins; 63 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From minqi at openjdk.java.net  Mon May 10 17:56:05 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 10 May 2021 17:56:05 GMT
Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated
 java.lang.invoke classes in CDS dynamic archive
Message-ID: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com>

Hi, please review
  This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. 
  The old PR description:
------------- old ------------
When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes,
"java.lang.invoke.Invokers$Holder",
"java.lang.invoke.DirectMethodHandle$Holder",
"java.lang.invoke.DelegatingMethodHandle$Holder",
"java.lang.invoke.LambdaForm$Holder"
which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
------------ new -------------
The new fix  (incremental)
1)  Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time  regeneration of holder class is reading from the list.
2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process.
3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. 
4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping.

Tests: tier1,tier2,tier3,tier4
           local test on runtime/cds
           local test ParallelLambdaLoadTest.java in loops without crash.

Thanks
Yumin

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

Commit messages:
 - 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive

Changes: https://git.openjdk.java.net/jdk/pull/3953/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266764
  Stats: 316 lines in 14 files changed: 243 ins; 29 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3953.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953

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

From zgu at openjdk.java.net  Mon May 10 18:02:56 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 10 May 2021 18:02:56 GMT
Subject: Integrated: 8266440: Shenandoah: TestReferenceShortcutCycle.java test
 failed on AArch64
In-Reply-To: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
References: <ct9Rnr2wDEzWMNhtadFCykyU0vqgkhXHH5cm6oyFUPE=.3ba1acd9-7ee9-4056-9d1f-3d38d58b9208@github.com>
Message-ID: <kCC3zyKraJCt0h2ilfoDFfYe39XgcWOtpMm8LCMkOoY=.bb88bb79-a03d-4fac-ac36-cbf3ea3afc54@github.com>

On Thu, 6 May 2021 14:40:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8263427 missed corresponding changes for aarch64.
> 
> LRB needs to be enabled during weak roots/references processing, regardless if heap is stable.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Macosx/AArch64
> - [ ] hotspot_gc_shenandoah on Linux 64/AArch64

This pull request has now been integrated.

Changeset: f78440ad
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f78440ad438bca2a8929475fbecfbd3c920d48df
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8266440: Shenandoah: TestReferenceShortcutCycle.java test failed on AArch64

Reviewed-by: aph

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

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

From mcimadamore at openjdk.java.net  Mon May 10 18:15:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 18:15:01 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <KROl8bMoZkWDj4sezvRJG898rwsIB-as99NnVfGErzA=.3008a688-e76f-4442-8585-a950fe41f983@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore 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 23 additional commits since the last revision:

 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
 - Fix message string in Reflection::ensureNativeAccess
 - Tweak comment in Module::enableNativeAccess
 - Tweak code some more
 - Use uniform naming convention for implementation metods in Module
 - Remove IllegalNativeAccessChecker
 - Remove redundant initializer in Module
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/bb4038eb...8de9da36

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3aaeb09f..8de9da36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13-14

  Stats: 33173 lines in 668 files changed: 19837 ins; 7268 del; 6068 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From mchung at openjdk.java.net  Mon May 10 19:20:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 10 May 2021 19:20:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: <KROl8bMoZkWDj4sezvRJG898rwsIB-as99NnVfGErzA=.3008a688-e76f-4442-8585-a950fe41f983@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <KROl8bMoZkWDj4sezvRJG898rwsIB-as99NnVfGErzA=.3008a688-e76f-4442-8585-a950fe41f983@github.com>
Message-ID: <NSBuSrQLuuI-XEzGoP-7xabhf-Htem-SiAwdqLPjeqI=.7a592f14-cda0-469a-bfde-a94f96a95334@github.com>

On Mon, 10 May 2021 18:15:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into JEP-412
>  - Remove redundant checks for --enable-native-access
>  - Fix issue in snippet in package-info
>  - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
>  - Fix message string in Reflection::ensureNativeAccess
>  - Tweak comment in Module::enableNativeAccess
>  - Tweak code some more
>  - Use uniform naming convention for implementation metods in Module
>  - Remove IllegalNativeAccessChecker
>  - Remove redundant initializer in Module
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5a35ba03...8de9da36

The caller-sensitive cleanup change looks good.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 148:

> 146:      * @throws IllegalArgumentException in the case of a method type and function descriptor mismatch.
> 147:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 148:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 147-148 are leftover from ICE and they should be removed.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 209:

> 207:      * than the thread owning {@code scope}.
> 208:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 209:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 208-209 are also left-over from the last patch.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java line 44:

> 42:     @CallerSensitive
> 43:     public final MethodHandle downcallHandle(Addressable symbol, MethodType type, FunctionDescriptor function) {
> 44:         Reflection.ensureNativeAccess(Reflection.getCallerClass());

`downcallHandle` method is no longer caller-sensitive.  `@CallerSensitive` and `Reflection.ensureNativeAccess` are no longer needed.    Same for the 4-arg `downcallHandle` method.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LibrariesHelper.java line 38:

> 36: import jdk.internal.loader.NativeLibrary;
> 37: import jdk.internal.reflect.CallerSensitive;
> 38: import jdk.internal.reflect.Reflection;

I think these 2 imports are no longer used.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java line 37:

> 35: import jdk.internal.foreign.abi.UpcallStubs;
> 36: import jdk.internal.reflect.CallerSensitive;
> 37: import jdk.internal.reflect.Reflection;

These 2 imports are no longer needed.  Same for other CLinker implementation classes.

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

Marked as reviewed by mchung (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon May 10 20:43:20 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:43:20 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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

  * Remove unused imports
  * Fix broken javadoc after removal of @throws clauses
  * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/8de9da36..6701654c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14-15

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

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

From mcimadamore at openjdk.java.net  Mon May 10 20:47:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:47:15 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <IajdP0aQ86wEmS6mETtAFsASUUyu_RfNwxoHcqf84SQ=.b34fb36b-2388-4e79-a114-d89b9587db88@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
 <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
 <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>
 <U05VgHVCM-mzgyvhcErkcFxVtzS24vAqCj-Y73tbgsU=.947cfa12-4f39-460c-9140-8bb82b4272cc@github.com>
 <UvyGpWdRxJDT1_J_okYNIP1JUQeGiar76pGQtxP4gNI=.bd657c24-2226-49c2-a3a7-1562bcffe93d@github.com>
 <z1iEfHGxloZm2O2AhKPq9y_zYwEGymaWSUDOzefVNE4=.a1e23412-73fa-4691-be18-4ae0c02e4a60@github.com>
 <IajdP0aQ86wEmS6mETtAFsASUUyu_RfNwxoHcqf84SQ=.b34fb36b-2388-4e79-a114-d89b9587db88@github.com>
Message-ID: <mUMiSxCjcu09VBkA3dtghZY13uZz76ntIIMdhlkxZHg=.df58c8a7-df17-4155-a8fc-fd889b97fa51@github.com>

On Fri, 30 Apr 2021 17:20:21 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration.
>> 
>> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
>> 
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
>
>> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
> 
> Thanks.
>  
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
> 
> I create JDK-8266383 and I will look into that.

Thanks for the review @mlchung - hopefully looks better now!

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

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

From vlivanov at openjdk.java.net  Mon May 10 21:07:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 10 May 2021 21:07:55 GMT
Subject: RFR: 8266317: Vector API enhancements
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: <UQRFvpszcJou1hKLebFnVHnuUCxSwoKIjfH1YhPf-wk=.a53371bb-2d4a-4f25-9c28-36323db20d71@github.com>

On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

Looks good.

src/hotspot/cpu/aarch64/aarch64.ad line 2440:

> 2438: }
> 2439: 
> 2440: bool Matcher::supports_unsigned_vector_comparison(int vlen, BasicType bt) {

`Matcher::supports_vector_comparison_unsigned()` looks a better fit.

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

Marked as reviewed by vlivanov (Reviewer).

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

From xliu at openjdk.java.net  Mon May 10 21:24:03 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 10 May 2021 21:24:03 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <lfkwGm9OKaffWF32feGpYCBdR1ClV4fIWWS8dj_xbd0=.5307c3f4-ff43-4158-98ab-5da2e7c8b41b@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
 <lfkwGm9OKaffWF32feGpYCBdR1ClV4fIWWS8dj_xbd0=.5307c3f4-ff43-4158-98ab-5da2e7c8b41b@github.com>
Message-ID: <7H-PeTwOrVwbLhxuH0Sofz7rk494D_BPZIHDg4hHLT8=.11410091-373e-4240-a33a-ffc4a985a44c@github.com>

On Fri, 7 May 2021 10:02:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> About synchronization: I don't understand the reasoning behind having a periodic flush. Would an implementation which just flushes if output is available not be less complex and actually better? Why make the flusher thread wake up twice a second if there is nothing to do? OTOH why wait 500ms if there is actually output to be printed?

>From my observation, the character of logging events is high-frequent but low cost. Using HotSpot Monitor(the combination of pthead_mutex_t and pthread_cond_t) for an individual logging event is expensive.  The cost of waking up AsyncLog thread and lock/unlock data structure would easily shadow IO jobs(fprintf), which usually are cached in libc.

My strategy is to do IO jobs in batch and amortize the cost of synchronizations.  In my design, m.wait() in the following code snippet wakes up mainly due to the load of buffer is over 3/4.   

  while (_state == ThreadState::Running) {
    {
      MonitorLocker m(&_lock, Mutex::_no_safepoint_check_flag);
      m.wait(500 /* ms, timeout*/);
    }
    flush();
  }


500ms here,  which was the global option `LogAsyncInterval` , serves as a **stall protector**.  If Hotspot stalls for whatever reasons, AsyncLog thread still can flush messages after timeout.  I think it's useful for develops who may rely on the log files to figure out what happened inside of the hanging hotspot.  Without timeout parameter, AsyncLog Thread may leave messages in the buffer and never get a change to flush them if all threads stall. 

>  IIUC this wait introduces an artificial 500ms delay on VM shutdown, since you have this handshake with the flusher thread which does an unconditional wait.
That's not true. In `LogAsyncFlusher::terminate`, I notify AsyncLog thread.  `m.wait(500 /* ms, timeout*/);` should return immediately once kernel wakes it up. 


    {
      MonitorLocker ml(&self->_lock, Mutex::_no_safepoint_check_flag);
      self->_state = ThreadState::Terminating;
      ml.notify();
    }


Actually, I admit that the termination protocol is overkill. I learned from WatchThreads. 
The bottom line is to make sure no message left behind.  This has been enforced by LogConfiguration::disable_outputs(). 
I added code change in disable_outputs() after terminate() to support jcmd's "VM.log disable". I will see if it's safe to remove `LogAsyncFlusher::terminate() `.

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

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

From psandoz at openjdk.java.net  Mon May 10 21:37:26 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 21:37:26 GMT
Subject: RFR: 8266317: Vector API enhancements [v2]
In-Reply-To: <UQRFvpszcJou1hKLebFnVHnuUCxSwoKIjfH1YhPf-wk=.a53371bb-2d4a-4f25-9c28-36323db20d71@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
 <UQRFvpszcJou1hKLebFnVHnuUCxSwoKIjfH1YhPf-wk=.a53371bb-2d4a-4f25-9c28-36323db20d71@github.com>
Message-ID: <-VH0nuTVCK1JwXG0B_4BUmrxhqKX6T1I5e6B81Gcj6E=.23cc42c0-7b89-48d5-bbe2-bf7b0557b3c6@github.com>

On Mon, 10 May 2021 21:05:02 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename method.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 2440:
> 
>> 2438: }
>> 2439: 
>> 2440: bool Matcher::supports_unsigned_vector_comparison(int vlen, BasicType bt) {
> 
> `Matcher::supports_vector_comparison_unsigned()` looks a better fit.

I renamed the method (see commit).

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

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

From psandoz at openjdk.java.net  Mon May 10 21:37:25 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 21:37:25 GMT
Subject: RFR: 8266317: Vector API enhancements [v2]
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: <dLdYqx0-EGF2T9v-EkrOLfIPpZxu-xAEtQ5b5MnhgL8=.259ef6ee-cd7f-4bac-b952-db59bcae551c@github.com>

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

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

  Rename method.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3803/files
  - new: https://git.openjdk.java.net/jdk/pull/3803/files/de210a88..93b093c1

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

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

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

From vlivanov at openjdk.java.net  Mon May 10 21:45:59 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 10 May 2021 21:45:59 GMT
Subject: RFR: 8266317: Vector API enhancements [v2]
In-Reply-To: <dLdYqx0-EGF2T9v-EkrOLfIPpZxu-xAEtQ5b5MnhgL8=.259ef6ee-cd7f-4bac-b952-db59bcae551c@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
 <dLdYqx0-EGF2T9v-EkrOLfIPpZxu-xAEtQ5b5MnhgL8=.259ef6ee-cd7f-4bac-b952-db59bcae551c@github.com>
Message-ID: <_XzaNLzjaTHQjUkhPO6Ur4ZR1hneCfa-gnqBS397jpA=.3685e964-bf60-4b04-9fdc-2e3d01960d6b@github.com>

On Mon, 10 May 2021 21:37:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
>> 
>> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
>> 
>> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename method.

Marked as reviewed by vlivanov (Reviewer).

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

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

From psandoz at openjdk.java.net  Mon May 10 21:58:14 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 21:58:14 GMT
Subject: RFR: 8266317: Vector API enhancements [v3]
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: <AFtZCQS-aUqoYkmNRZ3H3dluqRXR0x1vNSTON1BNXc4=.55a0714c-2338-4c6c-995c-b9a32b680d77@github.com>

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

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

  JavaDoc refs for unsigned operators.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3803/files
  - new: https://git.openjdk.java.net/jdk/pull/3803/files/93b093c1..aa6bb717

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

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

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

From mgkwill at openjdk.java.net  Mon May 10 22:32:45 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 10 May 2021 22:32:45 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <-u39zUYUkTGaDdiGLZOqym7B7oeSO4uHGhmPWKTMo3s=.42761688-cfc5-4265-aec8-21906371a998@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <-u39zUYUkTGaDdiGLZOqym7B7oeSO4uHGhmPWKTMo3s=.42761688-cfc5-4265-aec8-21906371a998@github.com>
Message-ID: <at3NlrLjH-XXRtRa8-bwuPnfJ9tYEDieS_14A4NURrw=.5eb2925c-831f-42db-b884-4f65b6a3e749@github.com>

On Sat, 8 May 2021 06:32:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The build warning makes not much sense to me, and is not reproducable. None of the callers of log_phase hands in any indentation > 4.
> 
> However, that indentation code is a bit inelegant anyway. @mgkwill : can you test this patch, does this fix your build? : https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/3934.diff
> 
> This uses outputStream::sp() to print indentation. Note that in places where that's not convenient, and I want to go via format string instead I usually do something like this:
> 
> ```
> static const char* spaces = "                        ...   ";
> ..
> out->print("%.*s", indentation, spaces);
> ```
> 
> That way you don't have to keep a const indentation string for every level. If you miss the assert, it could be squeezed in too.

Hi @tstuefe . Thanks for taking a look.

Your patch solved the issue in the last error message, but one remained:

In member function 'void G1GCPhaseTimes::details(T*, const char*) const [with T = WorkerDataArray<long unsigned int>]',
    inlined from 'void G1GCPhaseTimes::log_phase(WorkerDataArray<double>*, uint, outputStream*, bool) const' at /home/mgkwill/src/git/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:337:14,
    inlined from 'void G1GCPhaseTimes::trace_phase(WorkerDataArray<double>*, bool, uint) const' at /home/mgkwill/src/git/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:355:14:

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

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

From mgkwill at openjdk.java.net  Mon May 10 22:44:09 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 10 May 2021 22:44:09 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <YVcvYijv59RSIWZlX-waJf5ekIBFjVHIx2QHaFG3gPs=.22382b36-4c69-4d9c-be25-c57fdbfe7f1f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <YVcvYijv59RSIWZlX-waJf5ekIBFjVHIx2QHaFG3gPs=.22382b36-4c69-4d9c-be25-c57fdbfe7f1f@github.com>
Message-ID: <HZfqpFV9k63BI1fS0QDYh8Z9zV8d7A7QpMqUyfdV7Bc=.6a999b61-cc48-4591-9a15-4bcf9f6b6f70@github.com>

On Fri, 7 May 2021 20:47:26 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
>> 
>>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Merge branch 'master' into update_hlp
>>  - Remove extranous vm_page_size check
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - kstefanj review
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Set LargePageSizeInBytes to largepage upper limit
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Fix merge
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Merge branch 'master' into update_hlp
>>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4
>
>> I cloned openjdk/jdk and configured and `make` on main branch and I get the same result. Could it be my toolchain versions and recent changes clashing? `cc1plus: all warnings being treated as errors`?
> 
> Could be something like that. At least good to know it's not connected to the code in this PR.

Any suggestions or comments on current version of this change @kstefanj or @tstuefe?

After my local build is fixed, tests are passing here also:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/hotspot/jtreg/runtime/os/TestTracePageSizes.java
                                                         6     6     0     0
==============================
TEST SUCCESS


I'm doing some other testing to check a few things.

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

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

From sspitsyn at openjdk.java.net  Mon May 10 23:00:26 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 10 May 2021 23:00:26 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <wwW7kOkv6b7e9WIloNu1rWlOBsz3x-3db9YQQIDU7Ug=.704f8374-7f20-4a52-9306-ea823775c8a2@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108:

> 106: 
> 107: // caller needs ResourceMark
> 108: const char* get_java_thread_name(const JavaThread* t) {

Nit: Better to rename it: t => jt

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

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

From xliu at openjdk.java.net  Mon May 10 23:13:04 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 10 May 2021 23:13:04 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
 <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
Message-ID: <1GaDAyqOWvVq694wFltRAHzG_cw4zw3-GZ76sJfQXIo=.a11f73ea-1d67-40d1-ba2b-8b913a9b5930@github.com>

On Fri, 7 May 2021 08:24:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change option AsyncLogBufferEntries to AsyncLogBufferSize.
>>   
>>   AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
>>   User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 206:
> 
>> 204: 
>> 205: LogAsyncFlusher* LogAsyncFlusher::instance() {
>> 206:   if (Thread::current_or_null() != nullptr) {
> 
> I don't understand why this depends on the existence of a current thread? Ideally we should be able to log just fine in corner cases, e.g. when thread is detached or if we have an error (during signal handling e..g.)

`LogAsyncFlusher::enqueue` needs Thread::current() to use _lock. 

void Mutex::lock_without_safepoint_check() {
  lock_without_safepoint_check(Thread::current());
}


This check is for a very rare corner case.  This can be trigger using the following cmdline.
`
java -Xlog:'thread+smr=debug:file=/tmp/t.log' -Xlog:async -version
`
the root cause is the following code in thread


void ThreadsSMRSupport::smr_delete(JavaThread *thread) {
  elapsedTimer timer;
  if (EnableThreadSMRStatistics) {
    timer.start();
  }

  wait_until_not_protected(thread);

  delete thread; // Thread::current() will trigger assert(current != __null) failed: Thread::current() called on detached thread after ~Thread()
  if (EnableThreadSMRStatistics) {
    timer.stop();
    uint millis = (uint)timer.milliseconds();
    ThreadsSMRSupport::inc_deleted_thread_cnt();
    ThreadsSMRSupport::add_deleted_thread_times(millis);
    ThreadsSMRSupport::update_deleted_thread_time_max(millis);
  }
  // logsite will crash  in async mode because we can't use Thread::current() here. 
  log_debug(thread, smr)("tid=" UINTX_FORMAT ": ThreadsSMRSupport::smr_delete: thread=" INTPTR_FORMAT " is deleted.", os::current_thread_id(), p2i(thread));
}

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

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

From sspitsyn at openjdk.java.net  Mon May 10 23:14:07 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 10 May 2021 23:14:07 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <wGuqyHU3dhONZD-0jCs3eBvrtpC5SduvoXAAjthK3gQ=.5a6f7543-8e13-42ca-9469-b990ec004b4e@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

David,
This looks pretty good. At least, I do not see real problems.
It is really nice to make it more consistent.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dholmes at openjdk.java.net  Tue May 11 00:31:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 11 May 2021 00:31:35 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
 <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>
Message-ID: <tF1ODQcg65XtuZaHbfCtHI2r9ReizazZFztb5HgWRAQ=.98c6666a-5461-470b-b839-e094d387f2e4@github.com>

On Mon, 10 May 2021 17:40:51 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57:
>> 
>>> 55:         byte[] buf = new byte[100];
>>> 56:         int size = writeClass(buf, "MH$$");
>>> 57:         Class<?> cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null);
>> 
>> Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API?
>
> Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose.

But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ??

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

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

From david.holmes at oracle.com  Tue May 11 00:45:00 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 May 2021 10:45:00 +1000
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <Por8B_2H2aXaFmnnhzpq_wqAEf0MNzb6OjWY5dbSz2Q=.2918beff-cb20-469a-a710-3aa54f4e73ea@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <Por8B_2H2aXaFmnnhzpq_wqAEf0MNzb6OjWY5dbSz2Q=.2918beff-cb20-469a-a710-3aa54f4e73ea@github.com>
Message-ID: <1a6eeb30-1d67-b604-740d-682de612642c@oracle.com>

On 11/05/2021 3:43 am, Denghui Dong wrote:
> On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:
> 
>>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>>
>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    minor adjustment
> 
> Hi David,
> 
> Thanks for your comment!
> 
>> Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case?
> 
> Actually, the performance problem we noticed occurred in jdk 11u, here's a simplified piece of code:

Is there a real benchmark that demonstrates this, rather than a 
micro-benchmark? I'm just trying to understand under conditions this is 
a real problem.

> 
> import java.lang.invoke.*;
> import java.util.*;
> 
> class Test {
>      public static void main(String[] args) throws Throwable{
>          MethodType mt = MethodType.methodType(void.class);
> 
>          List<MethodHandle> mhs = new ArrayList<>();
>          for (int i = 0; i < 2000; i++) {
>              // In practice, it will point to different methods
>              mhs.add(MethodHandles.lookup().findVirtual(Test.class, "call",
>                                                         MethodType.methodType(void.class))
>                                   .bindTo(new Test()));
>          }
> 
>          for (int i = 0; i < 128; i++) {
>              for (MethodHandle mh : mhs) {
>                  mh.invokeExact();
>              }
>          }
>      }
> 
>      void call() {}
> }
> 
> 
> Run: `java -Xlog:membername+table=debug Test`, and we can see that all of the LambdaForm$MH use a same slot.
> 
> [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254840.invoke(Ljava/lang/Object;)V index 219
> [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254c40.invoke(Ljava/lang/Object;)V index 219
> [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255040.invoke(Ljava/lang/Object;)V index 219
> [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255440.invoke(Ljava/lang/Object;)V index 219
> 
> 
> 
> This problem doesn't exist in jdk upstream because of the name-mangling mechanism for hidden class(ClassFileParser::mangle_hidden_class_name).

Is the output above from JDK 17 or JDK 11? It seems to show the mangled 
(well "adorned") name, so shouldn't they map to different hash buckets 
anyway?

> However, if the user creates many classes with the same name by different classloaders, the performance problems will still appear, although I also think that the general user will not implement the code in this way.
> 
> My plan is to fix this problem in the upstream and then backport it to JDK 11, what do you think?

I'm not sure it is the right approach to "fix" a problem that doesn't 
really exist in mainline just so it can be backported to 11u

>> And what is the impact on other cases as we're now increasing the overhead of the hash computation.
> 
> I think the overhead is negligible, here is a benchmark based on ResolvedMethodTableHash.java:

Thanks for confirming.

David

> 
> import org.openjdk.jmh.annotations.Benchmark;
> import org.openjdk.jmh.annotations.Fork;
> import org.openjdk.jmh.annotations.Warmup;
> import org.openjdk.jmh.annotations.Setup;
> import org.openjdk.jmh.annotations.*;
> import org.openjdk.jmh.infra.Blackhole;
> 
> import java.lang.invoke.MethodHandle;
> import java.lang.invoke.MethodHandles;
> import java.lang.invoke.MethodType;
> import java.nio.ByteBuffer;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.Random;
> 
> @State(Scope.Benchmark)
> public class MyBenchmark extends ClassLoader {
> 
>      // Produce a class file with the given name and a single method:
>      //     public static native void m();
>      private int writeClass(byte[] buf, String className) {
>         ... same as ResolvedMethodTableHash.java
>      }
> 
>      private List<Class<?>> classes = new ArrayList<>();
>      private Random r = new Random();
> 
>      @Setup
>      public void prepare() throws Exception {
>          for (int i = 0; i < 5000; i ++) {
>              byte[] buf = new byte[100];
>              int size = writeClass(buf, "MH$" + i);
>              classes.add(defineClass(null, buf, 0, size));
>          }
>      }
> 
> 
>      @Benchmark
>      @Fork(value=1)
>      @Warmup(iterations = 5, time = 1)
>      public void test(Blackhole bh) throws Exception {
>          MethodHandle mh = MethodHandles.publicLookup().findStatic(classes.get(r.nextInt(5000)),
>                                                                    "m", MethodType.methodType(void.class));
>          if (mh == null) {
>              throw new RuntimeException();
>          }
>      }
> }
> 
> 
> on linux x86_64,
> 
> result with the patch:
> 
> Result: 904126.215 ?(99.9%) 26603.356 ops/s [Average]
>    Statistics: (min, avg, max) = (852079.715, 904126.215, 927791.630), stdev = 30636.464
>    Confidence interval (99.9%): [877522.859, 930729.571]
> 
> Benchmark                Mode  Samples       Score  Score error  Units
> o.s.MyBenchmark.test    thrpt       20  904126.215    26603.356  ops/s
> 
> 
> result without the patch:
> 
> Result: 883669.014 ?(99.9%) 26455.778 ops/s [Average]
>    Statistics: (min, avg, max) = (830830.551, 883669.014, 906978.220), stdev = 30466.514
>    Confidence interval (99.9%): [857213.236, 910124.792]
> 
> Benchmark                Mode  Samples       Score  Score error  Units
> o.s.MyBenchmark.test    thrpt       20  883669.014    26455.778  ops/s
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3901
> 

From david.holmes at oracle.com  Tue May 11 01:55:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 May 2021 11:55:58 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <wGuqyHU3dhONZD-0jCs3eBvrtpC5SduvoXAAjthK3gQ=.5a6f7543-8e13-42ca-9469-b990ec004b4e@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <wGuqyHU3dhONZD-0jCs3eBvrtpC5SduvoXAAjthK3gQ=.5a6f7543-8e13-42ca-9469-b990ec004b4e@github.com>
Message-ID: <c8dbf267-d635-0846-e905-fa06e2cebd15@oracle.com>

On 11/05/2021 9:14 am, Serguei Spitsyn wrote:
> On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
> David,
> This looks pretty good. At least, I do not see real problems.
> It is really nice to make it more consistent.
> Thanks,
> Serguei

Thanks for the review Serguei!

David

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

From dholmes at openjdk.java.net  Tue May 11 01:56:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 11 May 2021 01:56:09 GMT
Subject: RFR: 8252530: Fix inconsistencies in hotspot whitebox
In-Reply-To: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
References: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
Message-ID: <Xj1j5GZwQOHr0Q8xpD61QYvjvgUAHGOq0l4ebbfcQmM=.dd783892-e5ab-4f53-8727-5e09ade37f75@github.com>

On Fri, 7 May 2021 18:44:59 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Replace the runtime check and remove the "InVmBuild" suffix as described in the bug.

@marschall hotspot changes require at least two reviews (though only 1 official Reviewer) unless deemed to be trivial. So I will wait for a second review before sponsoring.

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

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

From dholmes at openjdk.java.net  Tue May 11 01:56:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 11 May 2021 01:56:21 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

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

  Review feedback from Serguei

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3877/files
  - new: https://git.openjdk.java.net/jdk/pull/3877/files/3b74085a..b08c19cb

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

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

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

From david.holmes at oracle.com  Tue May 11 01:58:27 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 May 2021 11:58:27 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <wwW7kOkv6b7e9WIloNu1rWlOBsz3x-3db9YQQIDU7Ug=.704f8374-7f20-4a52-9306-ea823775c8a2@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <wwW7kOkv6b7e9WIloNu1rWlOBsz3x-3db9YQQIDU7Ug=.704f8374-7f20-4a52-9306-ea823775c8a2@github.com>
Message-ID: <49ecd1f6-fdde-99eb-ea7f-82240615b68f@oracle.com>

On 11/05/2021 9:00 am, Serguei Spitsyn wrote:
> On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
> src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108:
> 
>> 106:
>> 107: // caller needs ResourceMark
>> 108: const char* get_java_thread_name(const JavaThread* t) {
> 
> Nit: Better to rename it: t => jt

Changed.

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

From ddong at openjdk.java.net  Tue May 11 02:37:51 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 11 May 2021 02:37:51 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <tF1ODQcg65XtuZaHbfCtHI2r9ReizazZFztb5HgWRAQ=.98c6666a-5461-470b-b839-e094d387f2e4@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
 <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>
 <tF1ODQcg65XtuZaHbfCtHI2r9ReizazZFztb5HgWRAQ=.98c6666a-5461-470b-b839-e094d387f2e4@github.com>
Message-ID: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com>

On Tue, 11 May 2021 00:27:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose.
>
> But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ??

Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream:

  // - for unsafe anonymous class: create a new CLD whith a class holder that uses
  //                               the same class loader as the unsafe_anonymous_host.
  // - for hidden classes that are not strong: create a new CLD that has a class holder and
  //                                           whose loader is the Lookup class's loader.
  // - for hidden class: add the class to the Lookup class's loader's CLD.

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

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

From david.holmes at oracle.com  Tue May 11 02:52:19 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 May 2021 12:52:19 +1000
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
 <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>
 <tF1ODQcg65XtuZaHbfCtHI2r9ReizazZFztb5HgWRAQ=.98c6666a-5461-470b-b839-e094d387f2e4@github.com>
 <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com>
Message-ID: <e5ea9cc5-9d88-8779-6a50-09ac763f736e@oracle.com>

On 11/05/2021 12:37 pm, Denghui Dong wrote:
> On Tue, 11 May 2021 00:27:47 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose.
>>
>> But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ??
> 
> Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream:
> 
>    // - for unsafe anonymous class: create a new CLD whith a class holder that uses
>    //                               the same class loader as the unsafe_anonymous_host.
>    // - for hidden classes that are not strong: create a new CLD that has a class holder and
>    //                                           whose loader is the Lookup class's loader.
>    // - for hidden class: add the class to the Lookup class's loader's CLD.

Okay but we should only be concerned about the behaviour of public 
API's, so we should be testing and benchmarking those API's.

defineAnonymousClass() maybe relevant for 11u, but not mainline.

Thanks,
David

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

From ddong at openjdk.java.net  Tue May 11 02:52:24 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 11 May 2021 02:52:24 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
Message-ID: <nqsywIu9PUsyu7KMJQv4y0i0yjfDCGn7h4QFDdgiK_U=.b4979cfb-c87d-403d-bab4-0419e060f643@github.com>

On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor adjustment

> Is there a real benchmark that demonstrates this, rather than a 
> micro-benchmark? I'm just trying to understand under conditions this is 
> a real problem.

Sorry, I don't have a real benchmark yet. 
I think the code snippets I provided before will exist in many current applications that rely on method handles.

> Is the output above from JDK 17 or JDK 11? It seems to show the mangled 
> (well "adorned") name, so shouldn't they map to different hash buckets 
> anyway?

>From JDK 11.
The reason why the name displayed in the log is different is because the external name of the target klass is used (see Method::name_and_sig_as_C_string), and in 11, all java.lang.invoke.LambdaForm$MH have the same name( that's why the slot index are the same).

> I'm not sure it is the right approach to "fix" a problem that doesn't 
> really exist in mainline just so it can be backported to 11u

>From my perspective, I think that this problem still exists in the mainline, but users will hardly write code that causes this problem.

Since this patch will not cause obvious performance problems, I think it is harmless to add it to the main-line.

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

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

From ddong at openjdk.java.net  Tue May 11 03:12:55 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 11 May 2021 03:12:55 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
 <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>
 <tF1ODQcg65XtuZaHbfCtHI2r9ReizazZFztb5HgWRAQ=.98c6666a-5461-470b-b839-e094d387f2e4@github.com>
 <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com>
Message-ID: <1luDs45T6ia9T_kzfLNCod2E36WrhmNZsGE8qnPxIqk=.da32b1d2-5b4f-4eba-af59-a559755f2651@github.com>

On Tue, 11 May 2021 02:35:13 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ??
>
> Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream:
> 
>   // - for unsafe anonymous class: create a new CLD whith a class holder that uses
>   //                               the same class loader as the unsafe_anonymous_host.
>   // - for hidden classes that are not strong: create a new CLD that has a class holder and
>   //                                           whose loader is the Lookup class's loader.
>   // - for hidden class: add the class to the Lookup class's loader's CLD.

> Okay but we should only be concerned about the behaviour of public 
> API's, so we should be testing and benchmarking those API's.

> defineAnonymousClass() maybe relevant for 11u, but not mainline.

I can use public API.
Another reason I used Unsafe API here is for saving metaspace.

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

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

From ddong at openjdk.java.net  Tue May 11 03:19:24 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 11 May 2021 03:19:24 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v3]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <8UENWXduGb1mHVlUEED98dvk8wCMFd1jlIYxkVT0mBk=.17d48971-8ff6-4a58-a687-7584a65f82de@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

Denghui Dong has updated the pull request incrementally with two additional commits since the last revision:

 - remove useless lines
 - use public api

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/8d500a84..82d8cc6c

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

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

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

From ddong at openjdk.java.net  Tue May 11 03:19:24 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 11 May 2021 03:19:24 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2]
In-Reply-To: <1luDs45T6ia9T_kzfLNCod2E36WrhmNZsGE8qnPxIqk=.da32b1d2-5b4f-4eba-af59-a559755f2651@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <RN_EzSawrDbX83U6s1oa4vqPmVnmMZLh2OhKBFoyb00=.e86955cd-f30f-4870-8066-005aee01d052@github.com>
 <E9jyWsOM9EOW6aC9EaGWCnnM9jehVXdUc8Ht9VWpf7k=.b45e2069-c3be-4101-ada3-f1313524b354@github.com>
 <r721sKC2s3PZGKqam9qiosUXni5ALhViqyP-_ELQ_P8=.5841a5b1-9f9b-46f7-b525-b0187f13ecd8@github.com>
 <tF1ODQcg65XtuZaHbfCtHI2r9ReizazZFztb5HgWRAQ=.98c6666a-5461-470b-b839-e094d387f2e4@github.com>
 <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com>
 <1luDs45T6ia9T_kzfLNCod2E36WrhmNZsGE8qnPxIqk=.da32b1d2-5b4f-4eba-af59-a559755f2651@github.com>
Message-ID: <uyqyA9FZX5N5BwNtOXIOK5ZXBOP5yfZk0iw1aZ688zc=.50b0d611-2838-416f-b42d-381b3cfb925f@github.com>

On Tue, 11 May 2021 03:10:20 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream:
>> 
>>   // - for unsafe anonymous class: create a new CLD whith a class holder that uses
>>   //                               the same class loader as the unsafe_anonymous_host.
>>   // - for hidden classes that are not strong: create a new CLD that has a class holder and
>>   //                                           whose loader is the Lookup class's loader.
>>   // - for hidden class: add the class to the Lookup class's loader's CLD.
>
>> Okay but we should only be concerned about the behaviour of public 
>> API's, so we should be testing and benchmarking those API's.
> 
>> defineAnonymousClass() maybe relevant for 11u, but not mainline.
> 
> I can use public API.
> Another reason I used Unsafe API here is for saving metaspace.

updated.

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

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

From dongbo at openjdk.java.net  Tue May 11 06:05:10 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 11 May 2021 06:05:10 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <rRTo1d5f2YmqJqS0LLvbpEYkbAAW4Ixdn61xjS1t61M=.a3795f9c-77af-43a6-af0a-92ff8a73b742@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
 <rRTo1d5f2YmqJqS0LLvbpEYkbAAW4Ixdn61xjS1t61M=.a3795f9c-77af-43a6-af0a-92ff8a73b742@github.com>
Message-ID: <2KqJJ5tCZUT3xNU7YmS8PohUBhSEIP7nmlOKYnSIeAg=.8e58f09b-d6e9-4c57-810e-081d735c46dc@github.com>

On Mon, 10 May 2021 14:29:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add assembler tests for smaxp/sminp
>
> Looking now. I can't quite understand how to run tests from panama-vector on JDK head. If the JMH test is relevant to JDK, not just panama-vector, why not add it to JDK?

> @theRealAph we are still working out how best to bring the vector performance tests over to the `test/micro` area of mainline. (Some preliminary work is [here](https://github.com/openjdk/panama-vector/pull/77)). The perf tests in the `panama-vector` are under a maven project and it should be possible to build/run that project with a mainline build of the JDK (the tests should be compatible).

Hi, @theRealAph @PaulSandoz. Thanks for the comments.

Because [1] has not been merged into mainline, we cannot build the tests directly with mainline JDK:

[ERROR] panama-vector/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/utf8/DecodeBench.java:[354,31] cannot find symbol
  symbol:   method intoCharArray(char[],int)
  location: class jdk.incubator.vector.ShortVector


When I tested this, the incompatible `DecodeBench.java` was deleted first since it is all about `ShortVector` and `ByteVector` rather than `Int64Vector`.
Then the perf tests were built/run with mainline builds of JDK:

mvn install
java -jar target/vector-benchmarks.jar benchmark.jdk.incubator.vector.Int64Vector.["M"|"ADD"]+[AXIN]*["Masked"]*Lanes -wi 10 -w 1000ms -f 1 -i 10 -r 1000ms


[1] https://github.com/openjdk/panama-vector/pull/22

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

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

From xliu at openjdk.java.net  Tue May 11 06:35:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 11 May 2021 06:35:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
Message-ID: <zjVD0HJ_Gpf9BCIgHFJSCIerB8iVJ7K_H1jeYkNB3Vk=.aebb13e0-24af-446f-8ffd-c0f77e0235c8@github.com>

On Thu, 6 May 2021 15:21:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.
>
> src/hotspot/share/logging/logAsyncFlusher.hpp line 86:
> 
>> 84:   LogFileOutput&   _output;
>> 85:   LogDecorations*  _decorations;
>> 86:   char*            _message;
> 
> I would keep decorations by value here. They are small enough.

I has changed that to by value. no perf regression has been detected. 
yes, there's one unnecessary copying imposed by <linkedlist.hpp> 
It's fine because you have shrunk sizeof(LogDecorations) a lot.

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

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

From stuefe at openjdk.java.net  Tue May 11 07:03:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 11 May 2021 07:03:07 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <k3rU06JqMQQbRMXM-kreRGYOkRNf4ESG9YOYBb66tP8=.e542fee7-83ea-4720-8e9c-9efcf14d76e9@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

Hi Marcus,

I have not forgotten this PR, but too much on my plate right now. However, I'd like to get this into JDK17 and will review it some time this week. For now I will feed the patch into our test systems, lets see how our more exotic architectures cope (64k pages on ppc, e.g.)

The patch is nicely contained now. Thank you both for all these cleanups!

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

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

From xxinliu at amazon.com  Tue May 11 07:53:08 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Tue, 11 May 2021 00:53:08 -0700
Subject: Request For Comment: Asynchronous Logging
In-Reply-To: <CA+3eh11dvq7yR9QVFES6J-g3m=59ORrUuAMRj0XEcuURF_x_iA@mail.gmail.com>
References: <CA+3eh11dvq7yR9QVFES6J-g3m=59ORrUuAMRj0XEcuURF_x_iA@mail.gmail.com>
Message-ID: <a6da0515-3f58-4642-fa37-6374383f138f@amazon.com>

Hi,

This RFC covers almost all aspects of async logging. Since then, we have
drawn many consensus and implemented them one by one.

I still have one open question. What's the discard policy?

Problem statement:
For async-logging, we proposed a lossy non-blocking design. that is to
say, the buffer is bounded and we have to drop messages for
non-blocking. The rationale was described: here:
https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487

The discard policy defines which message is dropped at logsite when the
buffer is full. There're at least 3 choices.
1. drop the oldest message and proceed to enqueue.
2. give up enqueue attempt. that is to say, the newest message is
discarded.
3. support them both, let user to choose.

It seems different data structures of buffer bias to different discard
policy. eg. printk of Linux kernel uses a fixed ringbuffer. It chooses
1) because that is naturally done by ringbuffer overwrite.

Folly logging library also supports async writing. They chose 2) because
it's straight-forward for a bounded array.
https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91

My current implementation is just in the middle two polar opinions. my
buffer is implemented using a linkedlist-based deque. It means that I
can pop elements from either sides. technically speaking, I can easily
support 2 discard policies.

In CSR, I wrote the following sentence in Solution section.
"On buffer exhaustion a message is discarded so that under no
circumstances will logging block threads. Which message is discarded
depends on implementation. In current implementation, the oldest message
is discarded to make room for the newest message. "

The reason I would like to "leave to implementation" because I don't
think it's a good idea to choose a discard policy in CSR. The wiggle
room can give more freedom for changing different data structures and
algorithms. David said we can't it undefined. If so, what's the discard
policy HotSpot prefers?

We have discussed it on CSR.
https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683

There are more audiences. Inputs are welcome.

FYI, current PR#3135 has implemented dropped message statistics. In the
log files, you would find meta messages to indicate how many messages
were lost. eg. line @34300:
34299-[trace][metaspace              ] Metaspace::allocate: type 7
return 0x00007fcf284fcb18.
34300:[warning][                       ]    529 messages dropped...
34301-[trace  ][metaspace              ] Arena @0x00007fcf80252df0
(non-class sm): after allocation: 1 chunk(s),
current:@0x00007fcf80243ef0, u, base 0x00007fcf28400000, level lv00
(524288), used: 132162, committed: 139264, committed-free: 7102

thanks,
--lx



On 3/30/21 11:18 AM, Volker Simonis wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hi,
> 
> I'd like to (re)start a discussion on asynchronous logging [1,2,3,4].
> We are successfully using this feature productively at Amazon both in
> jdk8 and jdk11 to reduce the tail latency of services which use
> logging. We think that async logging is a useful addition to the
> current logging framework which might be beneficial to a wider range
> of users. The following write-up tries to capture the comments and
> suggestions from the previous discussions we are aware of.
> 
> Current state:
> 
> - HotSpot uses the so called "Unified Logging" (UL) framework which
> was introduced by JEP 158 [5] in JDK 9. Most logs have been
> retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging"
> [6]).
> - The current UL implementation is based on the standard C buffered
> stream I/O interface [7]. The LogFileStreamOutput class which writes
> logs to abstract FILE streams is the only child of the abstract base
> class LogOutput. LogFileStreamOutput has three child classes
> LogStdoutOutput,  LogStderrOutput and LogFileOutput which write to
> stdout, stderr or an arbitrary file respectively. The initial UL JEP
> 158 [5] envisioned logging to a socket but has not implemented it. At
> least one such extension has been proposed since then [8].
> - UL synchronizes logs from different threads with the help of the
> standard C flockfile()/funlockfile() [9] functions. But even without
> this explicit locking, all the "stdio functions are thread-safe. This
> is achieved by assigning to each FILE object a lockcount and (if the
> lockcount is nonzero) an owning thread.  For each library call, these
> functions wait until the FILE object is no longer locked by a
> different thread, then lock it, do the requested I/O, and unlock the
> object again" [9]. A quick look at the glibc sources reveals that FILE
> locking is implemented with the help of futex() [10] which breaks down
> to s simple atomic compare and swap (CAS) on the fast path.
> - Notice that UL "synchronizes" logs from different threads to avoid
> log interleaving. But it does not "serialize" logs according to the
> time at which  they occurred. This is because the underlying stdio
> functions do not guarantee a specific order for different threads
> waiting on a locked FILE stream. E.g. if three log events A, B, C
> occur in that order, the first will lock the output stream. If the log
> events B and C both arrive while the stream is locked, it is
> unspecified which of B and C will be logged first after A releases the
> lock.
> 
> Problem statement:
> 
> - The amount of time a log event will block its FILE stream depends on
> the underlying file system. This can range from a few nanoseconds for
> in-memory file systems or milliseconds for physical discs under heavy
> load up to several seconds in the worst case scenario for e.g. network
> file systems. A blocked log output stream will block all concurrent
> threads which try to write log messages at the same time. If logging
> is done during a safepoint, this can significantly increase the
> safepoint time (e.g. several parallel GC threads trying to log at the
> same time). We can treat stdout/stderr as special files here without
> loss of generality.
> 
> Proposed solution:
> 
> Extend UL with an asynchronous logging facility. Asynchronous logging
> will be optional and disabled by default. It should have the following
> properties:
> - If disabled (the default) asynchronous logging should have no
> observable impact on logging.
> - If enabled, log messages will be stored in an intermediate data
> structure (e.g. a double ended queue).
> - A service thread will concurrently read and remove log messages from
> that data structure in a FIFO style and write them to the output
> stream
> - Storing log messages in the intermediate data structure should take
> constant time and not longer than logging a message takes in the
> traditional UL system (in general the time should be much shorter
> because the actual I/O is deferred).
> - Asynchronous logging trades memory overhead (i.e. the size of the
> intermediate data structure) for log accuracy. This means that in the
> unlikely case where the service thread which does the asynchronous
> logging falls behind the log producing threads, some logs might be
> lost. However, the probability for this to happen can be minimized by
> increasing the configurable size of the intermediate data structure.
> - The final output produced by asynchronous logging should be equal to
> the output from normal logging if no messages had to be dropped.
> Notice that in contrast to the traditional unified logging,
> asynchronous logging will give us the possibility to not only
> synchronize log events, but to optionally also serialize them based on
> their generation time if that's desired. This is because we are in
> full control of the synchronization primitives for the intermediate
> data structure which stores the logs.
> - If log messages had to be dropped, this should be logged in the log
> output (e.g. "[..] 42 messages dropped due to async logging")
> - Asynchronous logging should ideally be implemented in such a way
> that it can be easily adapted by alternative log targets like for
> example sockets in the future.
> 
> Alternative solutions:
> - It has repeatedly been suggested to place the log files into a
> memory file system but we don't think this is an optimal solution.
> Main memory is often a constrained resource and we don't want log
> files to compete with the JVM for it in such cases.
> - It has also been argued to place the log files on a fast file system
> which is only used for logging but in containerized environments file
> system are often virtualized and the properties of the underlying
> physical devices are not obvious.
> - The load on the file system might be unpredictable due to other
> applications on the same host.
> - All these workarounds won't work if we eventually implement direct
> logging to a network socket as suggested in [8].
> 
> Implementation details / POC:
> 
> - A recent pull request [2] for JDK-8229517 [3] proposed to use a
> simple deque implementation derived from HotSpot's LinkedListImpl
> class for the intermediate data structure. It synchronizes access to
> the queue with a MutexLocker which is internally implemented with
> pthread_lock() and results in an atomic CAS on the fast path. So
> performance-wise the locking itself is not different from the
> flockfile()/funlockfile() functionality currently used by UL but
> adding a log message to the deque should be constant as it basically
> only requires a strdup(). And we could even eliminate the strdup() if
> we'd pre-allocate a big enough array for holding the log messages as
> proposed in the pull request [2].
> - The pull pull request [2] for JDK-8229517 [3] proposed to set the
> async flag as an attribute of the Xlog option which feels more natural
> because UL configuration is traditionally done within the Xlog option.
> But we could just as well use a global -XX flag to enable async
> logging? What are your preferences here?
> - The pull pull request [2] for JDK-8229517 [3] (mis)uses the
> WatcherThread as service thread to concurrently process the
> intermediate data structure and write the log messages out to the log
> stream. That should definitely be changed to an independent service
> thread.
> - The pull pull request [2] for JDK-8229517 [3] initially proposed
> that the "service thread" runs at a fixed interval to dump log
> messages to the log streams. But reviewers commented that this should
> better happen either continuously or based on the filling level of the
> intermediate data structure. What are your preferences here?
> - What are your preferences on the configuration of the intermediate
> data structure? Should it be configured based on the maximum number of
> log messages it can store or rather on the total size of the stored
> log messages? I think that for normal runs this distinction probably
> won't make a big difference because the size of log messages will
> probably be the same on average so "number of log messages" should
> always be proportional to "total size of log mesages".
> 
> 1. Before diving into more implementation details, I'd first like to
> reach a general consensus that asynchronous logging is a useful
> feature that's worth while adding to HotSpot.
> 
> 2. Once we agree on that, we should agree on the desired properties of
> asynchronous logging. I've tried to collect a basic set in the
> "Proposed solution" section.
> 
> 3. If that's done as well, we can discuss various implementation
> details and finally prepare new pull requests.
> 
> Thank you and best regards,
> Volker
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8229517
> [2] https://github.com/openjdk/jdk/pull/3135
> [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
> [4] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
> [5] https://openjdk.java.net/jeps/158
> [6] https://openjdk.java.net/jeps/271
> [7] https://man7.org/linux/man-pages/man3/stdio.3.html
> [8] https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d
> [9] https://man7.org/linux/man-pages/man3/flockfile.3.html
> [10] https://man7.org/linux/man-pages/man2/futex.2.html
> 

From lukenbutters at gmail.com  Tue May 11 09:00:32 2021
From: lukenbutters at gmail.com (Luke B)
Date: Tue, 11 May 2021 19:00:32 +1000
Subject: I have test failures, is master the correct branch to build from?
Message-ID: <CAPYyR4_wm361+-cUh-WSW2qNkBQuhM4BSyxsvxAgZdZruDtoLA@mail.gmail.com>

Hi
I cloned git at github.com:openjdk/jdk.git followed the build instructions and
was able to build the JDK on master, however when I ran:

make run-test-tier1

some of the tests failed:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL
ERROR
>> jtreg:test/hotspot/jtreg:tier1                     1728  1721     7
0 <<
   jtreg:test/jdk:tier1                               2026  2026     0
0
   jtreg:test/langtools:tier1                         4167  4167     0
0
   jtreg:test/jaxp:tier1                                 0     0     0
0
   jtreg:test/lib-test:tier1                             0     0     0
0
==============================
TEST FAILURE

Looking in the report.html for the hotspot tests I see:
"native" failed 7 tests and "bug8251158 native" failed 2 tests.

This is running this on ubuntu 18.04.5

Is this expected, am I building the wrong branch? If not do I need to
install something to get those tests passing?

Should I be applying a ProblemList.txt, if so which one and how should that
be run? Perhaps I need to call jtreg directly rather than via make?

many thanks,
-Luke

From shade at redhat.com  Tue May 11 09:05:34 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 11 May 2021 11:05:34 +0200
Subject: I have test failures, is master the correct branch to build from?
In-Reply-To: <CAPYyR4_wm361+-cUh-WSW2qNkBQuhM4BSyxsvxAgZdZruDtoLA@mail.gmail.com>
References: <CAPYyR4_wm361+-cUh-WSW2qNkBQuhM4BSyxsvxAgZdZruDtoLA@mail.gmail.com>
Message-ID: <3e6f272d-8dcb-09b9-4d50-8330876ed83d@redhat.com>

On 5/11/21 11:00 AM, Luke B wrote:
> Looking in the report.html for the hotspot tests I see:
> "native" failed 7 tests and "bug8251158 native" failed 2 tests.

Please show the *names* of the failing tests, i.e. their file paths. And the gist of the failing 
test output (i.e. console output of "make run-test-tier1").

"bug8251158" suggests these are gtest tests?

$ ack 8251158 test/
test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java
28: * @bug 8251158
46: * @bug 8251158

test/hotspot/jtreg/gtest/MetaspaceGtests.java
33: * @bug 8251158
44: * @bug 8251158
57: * @bug 8251158
68: * @bug 8251158

So this might suggest you have a problem with google-test. tier1 passes well with 
googletest-release-1.8.1 for me.

> Is this expected, am I building the wrong branch? If not do I need to
> install something to get those tests passing?

tier1 is supposed to pass everywhere.

> Should I be applying a ProblemList.txt, if so which one and how should that
> be run? Perhaps I need to call jtreg directly rather than via make?

jtreg would hook up the default ProblemList.txt itself, you don't need to do anything else.

-- 
Thanks,
-Aleksey


From sjohanss at openjdk.java.net  Tue May 11 09:07:08 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 11 May 2021 09:07:08 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <-pA1zI7GMal-vkrjzsJAdy5NBYtVbHeY_hJTPE4Z0S0=.d13e5bc4-67fa-4f05-a078-6b0f1d6f969a@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

Some additional comments, mostly small nits. But this is really starting to look ready.

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

> 3605:         if (x && fgets(buf, sizeof(buf), fp) && strcmp(buf, " kB\n") == 0) {
> 3606:           default_large_page_size = x * K;
> 3607:           return default_large_page_size;

If we return here the we will not close the file, consider going back to using `break` or adding a call to `fclose(fp)`

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

> 3625:   // to discover the available page sizes
> 3626:   const char* sys_hugepages = "/sys/kernel/mm/hugepages";
> 3627:   static os::PageSizes page_sizes;

Any reason for this being `static`.

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

> 3750:   } else {
> 3751:     _large_page_size = default_large_page_size;
> 3752:   }

I would prefer turning this around a bit. Currently this will trigger an assert in all_large_pages.contains() if you set `LargePageSizeInBytes=0`. What do you think of instead first checking for the "default" case. Something like:
Suggestion:

  if (FLAG_IS_DEFAULT(LargePageSizeInBytes) ||
      LargePageSizeInBytes == 0 ||
      LargePageSizeInBytes == default_large_page_size) {
    _large_page_size = default_large_page_size;
    log_info(pagesize)("Using the default large page size: " SIZE_FORMAT "%s",
                       byte_size_in_exact_unit(_large_page_size),
                       exact_unit_for_byte_size(_large_page_size));
  } else {
    if (all_large_pages.contains(LargePageSizeInBytes)) {
      _large_page_size = LargePageSizeInBytes;
      log_info(pagesize)("Overriding default large page size (" SIZE_FORMAT "%s) "
                         "using LargePageSizeInBytes: " SIZE_FORMAT "%s",
                         byte_size_in_exact_unit(default_large_page_size),
                         exact_unit_for_byte_size(default_large_page_size),
                         byte_size_in_exact_unit(_large_page_size),
                         exact_unit_for_byte_size(_large_page_size));
    } else {
      _large_page_size = default_large_page_size;
      log_info(pagesize)("LargePageSizeInBytes is not a valid large page size (" SIZE_FORMAT "%s) "
                         "using the default large page size: " SIZE_FORMAT "%s",
                         byte_size_in_exact_unit(LargePageSizeInBytes),
                         exact_unit_for_byte_size(LargePageSizeInBytes),
                         byte_size_in_exact_unit(_large_page_size),
                         exact_unit_for_byte_size(_large_page_size));
    }
  }


I also added some additional logging for the three different cases.

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

> 3977:                                                         SIZE_FORMAT,
> 3978:                                                         page_size,
> 3979:                                                         (size_t)os::vm_page_size());

I would prefer keeping the assert message short as in the other cases.
Suggestion:

  assert(page_size > (size_t)os::vm_page_size(), "Must be a large page size");

Please also move it down to below the other assert checking `_page_sizes.contains(...)`

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

Changes requested by sjohanss (Reviewer).

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

From tschatzl at openjdk.java.net  Tue May 11 10:06:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 11 May 2021 10:06:55 GMT
Subject: RFR: 8233378: CHT: Fast reset
In-Reply-To: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
References: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
Message-ID: <sJr1Nm_tAdgpk9Nc5fcAzRKlLlGhVs7bJuOxBg9-gSc=.501bc6a1-1403-467c-9229-521720f234b4@github.com>

On Mon, 10 May 2021 14:08:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to add a dedicated method that just resets the internal table (optionally setting it to a new size) without going through new/delete of the CHT. Currently, the CHT destructor calls Value::destroy_node() on every element in the table which may be very slow for some use-cases.
> 
> Testing: tier 1-3 (Linux, Windows).

Lgtm

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

Marked as reviewed by tschatzl (Reviewer).

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

From iwalulya at openjdk.java.net  Tue May 11 10:06:55 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 11 May 2021 10:06:55 GMT
Subject: RFR: 8233378: CHT: Fast reset
In-Reply-To: <sJr1Nm_tAdgpk9Nc5fcAzRKlLlGhVs7bJuOxBg9-gSc=.501bc6a1-1403-467c-9229-521720f234b4@github.com>
References: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
 <sJr1Nm_tAdgpk9Nc5fcAzRKlLlGhVs7bJuOxBg9-gSc=.501bc6a1-1403-467c-9229-521720f234b4@github.com>
Message-ID: <UQdL4UzzEF66LnbEm1kb4xFYi_WE4-xWgIM-vWF80ck=.ee25cdef-d289-43d7-8f71-347e68c02970@github.com>

On Tue, 11 May 2021 10:02:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to add a dedicated method that just resets the internal table (optionally setting it to a new size) without going through new/delete of the CHT. Currently, the CHT destructor calls Value::destroy_node() on every element in the table which may be very slow for some use-cases.
>> 
>> Testing: tier 1-3 (Linux, Windows).
>
> Lgtm

Thanks @tschatzl

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

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

From thomas.stuefe at gmail.com  Tue May 11 10:08:58 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 11 May 2021 12:08:58 +0200
Subject: Request For Comment: Asynchronous Logging
In-Reply-To: <a6da0515-3f58-4642-fa37-6374383f138f@amazon.com>
References: <CA+3eh11dvq7yR9QVFES6J-g3m=59ORrUuAMRj0XEcuURF_x_iA@mail.gmail.com>
 <a6da0515-3f58-4642-fa37-6374383f138f@amazon.com>
Message-ID: <CAA-vtUz+1ia9tno=ORt9zj8bFV=LZObQZ+DLu9b530caDkTzng@mail.gmail.com>

Hi Xin, see my answer in the CSR.

Cheers, Thomas

On Tue, May 11, 2021 at 9:53 AM Liu, Xin <xxinliu at amazon.com> wrote:

> Hi,
>
> This RFC covers almost all aspects of async logging. Since then, we have
> drawn many consensus and implemented them one by one.
>
> I still have one open question. What's the discard policy?
>
> Problem statement:
> For async-logging, we proposed a lossy non-blocking design. that is to
> say, the buffer is bounded and we have to drop messages for
> non-blocking. The rationale was described: here:
> https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487
>
> The discard policy defines which message is dropped at logsite when the
> buffer is full. There're at least 3 choices.
> 1. drop the oldest message and proceed to enqueue.
> 2. give up enqueue attempt. that is to say, the newest message is
> discarded.
> 3. support them both, let user to choose.
>
> It seems different data structures of buffer bias to different discard
> policy. eg. printk of Linux kernel uses a fixed ringbuffer. It chooses
> 1) because that is naturally done by ringbuffer overwrite.
>
> Folly logging library also supports async writing. They chose 2) because
> it's straight-forward for a bounded array.
>
> https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91
>
> My current implementation is just in the middle two polar opinions. my
> buffer is implemented using a linkedlist-based deque. It means that I
> can pop elements from either sides. technically speaking, I can easily
> support 2 discard policies.
>
> In CSR, I wrote the following sentence in Solution section.
> "On buffer exhaustion a message is discarded so that under no
> circumstances will logging block threads. Which message is discarded
> depends on implementation. In current implementation, the oldest message
> is discarded to make room for the newest message. "
>
> The reason I would like to "leave to implementation" because I don't
> think it's a good idea to choose a discard policy in CSR. The wiggle
> room can give more freedom for changing different data structures and
> algorithms. David said we can't it undefined. If so, what's the discard
> policy HotSpot prefers?
>
> We have discussed it on CSR.
>
> https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683
>
> There are more audiences. Inputs are welcome.
>
> FYI, current PR#3135 has implemented dropped message statistics. In the
> log files, you would find meta messages to indicate how many messages
> were lost. eg. line @34300:
> 34299-[trace][metaspace              ] Metaspace::allocate: type 7
> return 0x00007fcf284fcb18.
> 34300:[warning][                       ]    529 messages dropped...
> 34301-[trace  ][metaspace              ] Arena @0x00007fcf80252df0
> (non-class sm): after allocation: 1 chunk(s),
> current:@0x00007fcf80243ef0, u, base 0x00007fcf28400000, level lv00
> (524288), used: 132162, committed: 139264, committed-free: 7102
>
> thanks,
> --lx
>
>
>
> On 3/30/21 11:18 AM, Volker Simonis wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
> >
> >
> >
> > Hi,
> >
> > I'd like to (re)start a discussion on asynchronous logging [1,2,3,4].
> > We are successfully using this feature productively at Amazon both in
> > jdk8 and jdk11 to reduce the tail latency of services which use
> > logging. We think that async logging is a useful addition to the
> > current logging framework which might be beneficial to a wider range
> > of users. The following write-up tries to capture the comments and
> > suggestions from the previous discussions we are aware of.
> >
> > Current state:
> >
> > - HotSpot uses the so called "Unified Logging" (UL) framework which
> > was introduced by JEP 158 [5] in JDK 9. Most logs have been
> > retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging"
> > [6]).
> > - The current UL implementation is based on the standard C buffered
> > stream I/O interface [7]. The LogFileStreamOutput class which writes
> > logs to abstract FILE streams is the only child of the abstract base
> > class LogOutput. LogFileStreamOutput has three child classes
> > LogStdoutOutput,  LogStderrOutput and LogFileOutput which write to
> > stdout, stderr or an arbitrary file respectively. The initial UL JEP
> > 158 [5] envisioned logging to a socket but has not implemented it. At
> > least one such extension has been proposed since then [8].
> > - UL synchronizes logs from different threads with the help of the
> > standard C flockfile()/funlockfile() [9] functions. But even without
> > this explicit locking, all the "stdio functions are thread-safe. This
> > is achieved by assigning to each FILE object a lockcount and (if the
> > lockcount is nonzero) an owning thread.  For each library call, these
> > functions wait until the FILE object is no longer locked by a
> > different thread, then lock it, do the requested I/O, and unlock the
> > object again" [9]. A quick look at the glibc sources reveals that FILE
> > locking is implemented with the help of futex() [10] which breaks down
> > to s simple atomic compare and swap (CAS) on the fast path.
> > - Notice that UL "synchronizes" logs from different threads to avoid
> > log interleaving. But it does not "serialize" logs according to the
> > time at which  they occurred. This is because the underlying stdio
> > functions do not guarantee a specific order for different threads
> > waiting on a locked FILE stream. E.g. if three log events A, B, C
> > occur in that order, the first will lock the output stream. If the log
> > events B and C both arrive while the stream is locked, it is
> > unspecified which of B and C will be logged first after A releases the
> > lock.
> >
> > Problem statement:
> >
> > - The amount of time a log event will block its FILE stream depends on
> > the underlying file system. This can range from a few nanoseconds for
> > in-memory file systems or milliseconds for physical discs under heavy
> > load up to several seconds in the worst case scenario for e.g. network
> > file systems. A blocked log output stream will block all concurrent
> > threads which try to write log messages at the same time. If logging
> > is done during a safepoint, this can significantly increase the
> > safepoint time (e.g. several parallel GC threads trying to log at the
> > same time). We can treat stdout/stderr as special files here without
> > loss of generality.
> >
> > Proposed solution:
> >
> > Extend UL with an asynchronous logging facility. Asynchronous logging
> > will be optional and disabled by default. It should have the following
> > properties:
> > - If disabled (the default) asynchronous logging should have no
> > observable impact on logging.
> > - If enabled, log messages will be stored in an intermediate data
> > structure (e.g. a double ended queue).
> > - A service thread will concurrently read and remove log messages from
> > that data structure in a FIFO style and write them to the output
> > stream
> > - Storing log messages in the intermediate data structure should take
> > constant time and not longer than logging a message takes in the
> > traditional UL system (in general the time should be much shorter
> > because the actual I/O is deferred).
> > - Asynchronous logging trades memory overhead (i.e. the size of the
> > intermediate data structure) for log accuracy. This means that in the
> > unlikely case where the service thread which does the asynchronous
> > logging falls behind the log producing threads, some logs might be
> > lost. However, the probability for this to happen can be minimized by
> > increasing the configurable size of the intermediate data structure.
> > - The final output produced by asynchronous logging should be equal to
> > the output from normal logging if no messages had to be dropped.
> > Notice that in contrast to the traditional unified logging,
> > asynchronous logging will give us the possibility to not only
> > synchronize log events, but to optionally also serialize them based on
> > their generation time if that's desired. This is because we are in
> > full control of the synchronization primitives for the intermediate
> > data structure which stores the logs.
> > - If log messages had to be dropped, this should be logged in the log
> > output (e.g. "[..] 42 messages dropped due to async logging")
> > - Asynchronous logging should ideally be implemented in such a way
> > that it can be easily adapted by alternative log targets like for
> > example sockets in the future.
> >
> > Alternative solutions:
> > - It has repeatedly been suggested to place the log files into a
> > memory file system but we don't think this is an optimal solution.
> > Main memory is often a constrained resource and we don't want log
> > files to compete with the JVM for it in such cases.
> > - It has also been argued to place the log files on a fast file system
> > which is only used for logging but in containerized environments file
> > system are often virtualized and the properties of the underlying
> > physical devices are not obvious.
> > - The load on the file system might be unpredictable due to other
> > applications on the same host.
> > - All these workarounds won't work if we eventually implement direct
> > logging to a network socket as suggested in [8].
> >
> > Implementation details / POC:
> >
> > - A recent pull request [2] for JDK-8229517 [3] proposed to use a
> > simple deque implementation derived from HotSpot's LinkedListImpl
> > class for the intermediate data structure. It synchronizes access to
> > the queue with a MutexLocker which is internally implemented with
> > pthread_lock() and results in an atomic CAS on the fast path. So
> > performance-wise the locking itself is not different from the
> > flockfile()/funlockfile() functionality currently used by UL but
> > adding a log message to the deque should be constant as it basically
> > only requires a strdup(). And we could even eliminate the strdup() if
> > we'd pre-allocate a big enough array for holding the log messages as
> > proposed in the pull request [2].
> > - The pull pull request [2] for JDK-8229517 [3] proposed to set the
> > async flag as an attribute of the Xlog option which feels more natural
> > because UL configuration is traditionally done within the Xlog option.
> > But we could just as well use a global -XX flag to enable async
> > logging? What are your preferences here?
> > - The pull pull request [2] for JDK-8229517 [3] (mis)uses the
> > WatcherThread as service thread to concurrently process the
> > intermediate data structure and write the log messages out to the log
> > stream. That should definitely be changed to an independent service
> > thread.
> > - The pull pull request [2] for JDK-8229517 [3] initially proposed
> > that the "service thread" runs at a fixed interval to dump log
> > messages to the log streams. But reviewers commented that this should
> > better happen either continuously or based on the filling level of the
> > intermediate data structure. What are your preferences here?
> > - What are your preferences on the configuration of the intermediate
> > data structure? Should it be configured based on the maximum number of
> > log messages it can store or rather on the total size of the stored
> > log messages? I think that for normal runs this distinction probably
> > won't make a big difference because the size of log messages will
> > probably be the same on average so "number of log messages" should
> > always be proportional to "total size of log mesages".
> >
> > 1. Before diving into more implementation details, I'd first like to
> > reach a general consensus that asynchronous logging is a useful
> > feature that's worth while adding to HotSpot.
> >
> > 2. Once we agree on that, we should agree on the desired properties of
> > asynchronous logging. I've tried to collect a basic set in the
> > "Proposed solution" section.
> >
> > 3. If that's done as well, we can discuss various implementation
> > details and finally prepare new pull requests.
> >
> > Thank you and best regards,
> > Volker
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8229517
> > [2] https://github.com/openjdk/jdk/pull/3135
> > [3]
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
> > [4]
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
> > [5] https://openjdk.java.net/jeps/158
> > [6] https://openjdk.java.net/jeps/271
> > [7] https://man7.org/linux/man-pages/man3/stdio.3.html
> > [8] https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d
> > [9] https://man7.org/linux/man-pages/man3/flockfile.3.html
> > [10] https://man7.org/linux/man-pages/man2/futex.2.html
> >
>

From iwalulya at openjdk.java.net  Tue May 11 10:08:21 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 11 May 2021 10:08:21 GMT
Subject: RFR: 8266637: CHT: Add insert_and_get method
In-Reply-To: <WB63CsVG_kJesDoclESB1Cm61muSDXPSsVG0_CzPmyY=.81f68875-1f4a-4251-8f08-5d6fccf54d7d@github.com>
References: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
 <WB63CsVG_kJesDoclESB1Cm61muSDXPSsVG0_CzPmyY=.81f68875-1f4a-4251-8f08-5d6fccf54d7d@github.com>
Message-ID: <Fp1_G-SOBkqqkwKOJ_wGwxngeKtubHqZTCPqTlfnhj0=.0b21acb7-b97a-491d-8e5c-41b4689ce2f8@github.com>

On Mon, 10 May 2021 09:08:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to add an `insert_get` method to the CHT.  The method combines `insert()` and `get()` methods to decrease the amount of global synchronization needed for `get()` calls after an `insert` call. 
>> 
>> Testing: tier1-3
>
> Lgtm, but wait for a runtime team reviewer.

Thanks @tschatzl

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

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

From ayang at openjdk.java.net  Tue May 11 10:48:19 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 May 2021 10:48:19 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods [v2]
In-Reply-To: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
Message-ID: <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>

> Adding the assertion, and fixing a benign violation.
> 
> Test: tier1-7; no violation of this assertion.

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

 - merge master
 - delta

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

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

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

From thomas.stuefe at gmail.com  Tue May 11 11:23:53 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 11 May 2021 13:23:53 +0200
Subject: I have test failures, is master the correct branch to build from?
In-Reply-To: <3e6f272d-8dcb-09b9-4d50-8330876ed83d@redhat.com>
References: <CAPYyR4_wm361+-cUh-WSW2qNkBQuhM4BSyxsvxAgZdZruDtoLA@mail.gmail.com>
 <3e6f272d-8dcb-09b9-4d50-8330876ed83d@redhat.com>
Message-ID: <CAA-vtUwAnBsV3_nnqY_KhxGUr0vVCSqeKSJVN2Y01Z3Lqq_bYA@mail.gmail.com>

On Tue, May 11, 2021 at 11:06 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 5/11/21 11:00 AM, Luke B wrote:
> > Looking in the report.html for the hotspot tests I see:
> > "native" failed 7 tests and "bug8251158 native" failed 2 tests.
>
> Please show the *names* of the failing tests, i.e. their file paths. And
> the gist of the failing
> test output (i.e. console output of "make run-test-tier1").
>
> "bug8251158" suggests these are gtest tests?
>
> $ ack 8251158 test/
> test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java
> 28: * @bug 8251158
> 46: * @bug 8251158
>
> test/hotspot/jtreg/gtest/MetaspaceGtests.java
> 33: * @bug 8251158
> 44: * @bug 8251158
> 57: * @bug 8251158
> 68: * @bug 8251158
>
> So this might suggest you have a problem with google-test. tier1 passes
> well with
> googletest-release-1.8.1 for me.
>
>
@Luke: did you build with --with-gtest? That is needed for these tests.

Cheers, Thomas


> > Is this expected, am I building the wrong branch? If not do I need to
> > install something to get those tests passing?
>
> tier1 is supposed to pass everywhere.
>
> > Should I be applying a ProblemList.txt, if so which one and how should
> that
> > be run? Perhaps I need to call jtreg directly rather than via make?
>
> jtreg would hook up the default ProblemList.txt itself, you don't need to
> do anything else.
>
> --
> Thanks,
> -Aleksey
>
>

From stuefe at openjdk.java.net  Tue May 11 11:23:06 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 11 May 2021 11:23:06 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <hTO2yIX9M67DHSDQAjlh89TfSF_DHTRBtTs93-v4Pj4=.c53c09e3-4093-4a8a-9648-44e7acae4055@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

Not much to add to Stefans remarks.

--Thomas

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

> 3763:     LogStream ls(lt);
> 3764:     ls.print("Available page sizes: ");
> 3765:     _page_sizes.print_on(&ls);

I'd prefer to log *all* page sizes, not the filtered list we use. Or print both, "All" and "Usable"?

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

Changes requested by stuefe (Reviewer).

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

From stuefe at openjdk.java.net  Tue May 11 11:23:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 11 May 2021 11:23:07 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <-pA1zI7GMal-vkrjzsJAdy5NBYtVbHeY_hJTPE4Z0S0=.d13e5bc4-67fa-4f05-a078-6b0f1d6f969a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <-pA1zI7GMal-vkrjzsJAdy5NBYtVbHeY_hJTPE4Z0S0=.d13e5bc4-67fa-4f05-a078-6b0f1d6f969a@github.com>
Message-ID: <_e8vL6XFJyaDoVCzzeSL6pYGZZFCYdAl7xq8MMXkuZ8=.125f459f-6c3a-4c2e-834b-acd19a716fe0@github.com>

On Tue, 11 May 2021 08:41:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
>> 
>>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Merge branch 'master' into update_hlp
>>  - Remove extranous vm_page_size check
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - kstefanj review
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Set LargePageSizeInBytes to largepage upper limit
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Fix merge
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Merge branch 'master' into update_hlp
>>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4
>
> src/hotspot/os/linux/os_linux.cpp line 3752:
> 
>> 3750:   } else {
>> 3751:     _large_page_size = default_large_page_size;
>> 3752:   }
> 
> I would prefer turning this around a bit. Currently this will trigger an assert in all_large_pages.contains() if you set `LargePageSizeInBytes=0`. What do you think of instead first checking for the "default" case. Something like:
> Suggestion:
> 
>   if (FLAG_IS_DEFAULT(LargePageSizeInBytes) ||
>       LargePageSizeInBytes == 0 ||
>       LargePageSizeInBytes == default_large_page_size) {
>     _large_page_size = default_large_page_size;
>     log_info(pagesize)("Using the default large page size: " SIZE_FORMAT "%s",
>                        byte_size_in_exact_unit(_large_page_size),
>                        exact_unit_for_byte_size(_large_page_size));
>   } else {
>     if (all_large_pages.contains(LargePageSizeInBytes)) {
>       _large_page_size = LargePageSizeInBytes;
>       log_info(pagesize)("Overriding default large page size (" SIZE_FORMAT "%s) "
>                          "using LargePageSizeInBytes: " SIZE_FORMAT "%s",
>                          byte_size_in_exact_unit(default_large_page_size),
>                          exact_unit_for_byte_size(default_large_page_size),
>                          byte_size_in_exact_unit(_large_page_size),
>                          exact_unit_for_byte_size(_large_page_size));
>     } else {
>       _large_page_size = default_large_page_size;
>       log_info(pagesize)("LargePageSizeInBytes is not a valid large page size (" SIZE_FORMAT "%s) "
>                          "using the default large page size: " SIZE_FORMAT "%s",
>                          byte_size_in_exact_unit(LargePageSizeInBytes),
>                          exact_unit_for_byte_size(LargePageSizeInBytes),
>                          byte_size_in_exact_unit(_large_page_size),
>                          exact_unit_for_byte_size(_large_page_size));
>     }
>   }
> 
> 
> I also added some additional logging for the three different cases.

+1 for the added warning if the page size given was invalid/not available.

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

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

From shade at openjdk.java.net  Tue May 11 12:27:59 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 11 May 2021 12:27:59 GMT
Subject: RFR: 8266813: Use shorter instruction sequence for checking if
 marking in progress
In-Reply-To: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>
References: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>
Message-ID: <RSj0D2p3YaW2YenMwB5H9SAXW9OC4pmSixKRvhFp3FA=.dac9113b-1f00-4053-99ca-0050aad556d1@github.com>

On Mon, 10 May 2021 13:21:44 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahBarrierSetAssembler::generate_c1_pre_barrier_runtime_stub() on aarch64, we can replace ld, tst, br instruction sequence with a single tbz.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux aarch64

PR title mismatches, BTW.

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

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

From zgu at openjdk.java.net  Tue May 11 12:53:11 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 11 May 2021 12:53:11 GMT
Subject: Integrated: 8266813: Shenandoah: Use shorter instruction sequence for
 checking if marking in progress
In-Reply-To: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>
References: <yeombb6w6WduVD-KsuJ-_89WLX42tgN-Fr9lOkyzKXk=.f835637c-eb02-4d58-b56a-1739487f8378@github.com>
Message-ID: <Y5xSwi46OEJk5CZaY1E7UoShlyYiTs4YmUbLSXtEBO0=.798acb9e-f9dd-4f5f-8b83-14e3868afce2@github.com>

On Mon, 10 May 2021 13:21:44 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahBarrierSetAssembler::generate_c1_pre_barrier_runtime_stub() on aarch64, we can replace ld, tst, br instruction sequence with a single tbz.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux aarch64

This pull request has now been integrated.

Changeset: 9c9c47e4
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c9c47e403c6d38afd1ce89f46a1887a01964796
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8266813: Shenandoah: Use shorter instruction sequence for checking if marking in progress

Reviewed-by: shade

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

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

From hseigel at openjdk.java.net  Tue May 11 12:58:07 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 12:58:07 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
Message-ID: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>

Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.

This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8243287: Removal of Unsafe::defineAnonymousClass

Changes: https://git.openjdk.java.net/jdk/pull/3974/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
  Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

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

From tschatzl at openjdk.java.net  Tue May 11 13:15:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 11 May 2021 13:15:10 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
Message-ID: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>

Hi all,

  can I have reviews for this change that improves performance of the merge heap roots phase in g1?

Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.

Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).

Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 

Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).

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

Commit messages:
 - Initial version, prefetch remembered set and log buffer merging

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

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

From rehn at openjdk.java.net  Tue May 11 13:19:23 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 11 May 2021 13:19:23 GMT
Subject: RFR: 8233378: CHT: Fast reset
In-Reply-To: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
References: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
Message-ID: <CGMTE_a6CaDsisJJ7gagj6R0v1fVRY8nZn30-TjLeU0=.2bb0444c-d133-4540-a0ba-860734298630@github.com>

On Mon, 10 May 2021 14:08:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to add a dedicated method that just resets the internal table (optionally setting it to a new size) without going through new/delete of the CHT. Currently, the CHT destructor calls Value::destroy_node() on every element in the table which may be very slow for some use-cases.
> 
> Testing: tier 1-3 (Linux, Windows).

Looks ok! Thanks for also adding the gtests.

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

Marked as reviewed by rehn (Reviewer).

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

From brian.goetz at oracle.com  Tue May 11 13:20:27 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 11 May 2021 13:20:27 +0000
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>

There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?

Sent from my iPad

> On May 11, 2021, at 8:59 AM, Harold Seigel <hseigel at openjdk.java.net> wrote:
> 
> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold
> 
> -------------
> 
> Commit messages:
> - 8243287: Removal of Unsafe::defineAnonymousClass
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>  Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
> 
> PR: https://git.openjdk.java.net/jdk/pull/3974

From iwalulya at openjdk.java.net  Tue May 11 13:29:08 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 11 May 2021 13:29:08 GMT
Subject: RFR: 8233378: CHT: Fast reset
In-Reply-To: <CGMTE_a6CaDsisJJ7gagj6R0v1fVRY8nZn30-TjLeU0=.2bb0444c-d133-4540-a0ba-860734298630@github.com>
References: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
 <CGMTE_a6CaDsisJJ7gagj6R0v1fVRY8nZn30-TjLeU0=.2bb0444c-d133-4540-a0ba-860734298630@github.com>
Message-ID: <1bS2wdkpJoz8SWtPhH2_Gao_Lq5ShLuoHTYEnVZ3uys=.ee2d15ab-cecf-4089-a419-9f99ca9aefbd@github.com>

On Tue, 11 May 2021 13:16:00 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to add a dedicated method that just resets the internal table (optionally setting it to a new size) without going through new/delete of the CHT. Currently, the CHT destructor calls Value::destroy_node() on every element in the table which may be very slow for some use-cases.
>> 
>> Testing: tier 1-3 (Linux, Windows).
>
> Looks ok! Thanks for also adding the gtests.

Thanks @robehn

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

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

From alanb at openjdk.java.net  Tue May 11 13:40:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:40:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>

On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

test/jdk/java/lang/Class/GetModuleTest.java line 42:

> 40: import static org.testng.Assert.*;
> 41: 
> 42: public class GetModuleTest {

testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.

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

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

From alanb at openjdk.java.net  Tue May 11 13:45:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:45:01 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
Message-ID: <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>

On Tue, 11 May 2021 13:37:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> test/jdk/java/lang/Class/GetModuleTest.java line 42:
> 
>> 40: import static org.testng.Assert.*;
>> 41: 
>> 42: public class GetModuleTest {
> 
> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.

Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.

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

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

From rkennke at redhat.com  Tue May 11 13:50:00 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 11 May 2021 15:50:00 +0200
Subject: Timeline for BiasedLocking removal?
Message-ID: <4aa813a6-c8ce-86ca-d2bd-ba87ea561773@redhat.com>

Hi Hotspot devs,

what is the timeline for removing BiasedLocking altogether? Or have we 
even agreed that we are going to remove it?

I am asking because this affects how I'd move forward with Lilliput. If 
I can ignore BiasedLocking because it'd be removed in, say, JDK 18 
anyway, then I believe I can come up with a relatively simple 
implementation for 64bit header that should be possible to integrate 
into JDK 18. That is, I put the (compressed) Klass* in the upper bits of 
the header, also keep the hashcode in the header, and keep everything 
else (locking, GC bits) as they are.

With biased-locking, the Klass* would clash with the Thread* in the 
upper bits. If we are not going to remove BiasedLocking anytime soon, I 
would have to come up with a different plan.

(Also, note that I expect the performance improvement of Lilliput to 
outweight possible - and hopefully rare - biased-locking removal 
regressions)

WDYT?

Cheers,
Roman


From daniel.daugherty at oracle.com  Tue May 11 13:52:51 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Tue, 11 May 2021 09:52:51 -0400
Subject: Timeline for BiasedLocking removal?
In-Reply-To: <4aa813a6-c8ce-86ca-d2bd-ba87ea561773@redhat.com>
References: <4aa813a6-c8ce-86ca-d2bd-ba87ea561773@redhat.com>
Message-ID: <c9795241-dce3-59df-f7b5-88ac1068d710@oracle.com>

JDK-8256425 Obsolete Biased Locking in JDK 18
https://bugs.openjdk.java.net/browse/JDK-8256425

On 5/11/21 9:50 AM, Roman Kennke wrote:
> Hi Hotspot devs,
>
> what is the timeline for removing BiasedLocking altogether? Or have we 
> even agreed that we are going to remove it?
>
> I am asking because this affects how I'd move forward with Lilliput. 
> If I can ignore BiasedLocking because it'd be removed in, say, JDK 18 
> anyway, then I believe I can come up with a relatively simple 
> implementation for 64bit header that should be possible to integrate 
> into JDK 18. That is, I put the (compressed) Klass* in the upper bits 
> of the header, also keep the hashcode in the header, and keep 
> everything else (locking, GC bits) as they are.
>
> With biased-locking, the Klass* would clash with the Thread* in the 
> upper bits. If we are not going to remove BiasedLocking anytime soon, 
> I would have to come up with a different plan.
>
> (Also, note that I expect the performance improvement of Lilliput to 
> outweight possible - and hopefully rare - biased-locking removal 
> regressions)
>
> WDYT?
>
> Cheers,
> Roman
>


From hseigel at openjdk.java.net  Tue May 11 14:10:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:10:42 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v2]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <LbwuOkUqTA3ZEXoxdHChL_TtrtrlnYOPpgOY_0-4Sjg=.29528c34-6554-4452-82c1-c636c677e4be@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  test fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/233a4725..35c6634c

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

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

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

From hseigel at openjdk.java.net  Tue May 11 14:13:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:13:49 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  fix GetModuleTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/35c6634c..874a1603

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

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

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

From hseigel at openjdk.java.net  Tue May 11 14:13:51 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:13:51 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
 <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>
Message-ID: <D3MaVYi6Rdq6cEhXousz4fIcsEZsYj7D-MJyxP7dqKs=.221945b9-53c8-4339-9f6e-ec36dc625abe@github.com>

On Tue, 11 May 2021 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/Class/GetModuleTest.java line 42:
>> 
>>> 40: import static org.testng.Assert.*;
>>> 41: 
>>> 42: public class GetModuleTest {
>> 
>> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.
>
> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.

Hi Alan,
Thanks for find this.  I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java.
Thanks, Harold

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

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

From harold.seigel at oracle.com  Tue May 11 14:15:10 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Tue, 11 May 2021 10:15:10 -0400
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
Message-ID: <8013d5ad-b06f-29c1-9287-e3408ec86413@oracle.com>

Hi Brian,

Thanks for looking at this.

The JDK no longer creates unsafe anon classes.? So, those tests could 
only find an unsafe anonymous class if they explicitly created one.? In 
which case, the tests would need to call Unsafe.defineAnonymousClass().? 
And, hopefully, those tests have been handled in this webrev.

If there are dead tests then they probably died when the JDK stopped 
creating unsafe anon classes.? Note that none of them showed up as 
failures during regression testing.

Harold

On 5/11/2021 9:20 AM, Brian Goetz wrote:
> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>
> Sent from my iPad
>
>> On May 11, 2021, at 8:59 AM, Harold Seigel <hseigel at openjdk.java.net> wrote:
>>
>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>
>> Thanks, Harold
>>
>> -------------
>>
>> Commit messages:
>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3974

From akozlov at openjdk.java.net  Tue May 11 15:09:25 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 11 May 2021 15:09:25 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS [v2]
In-Reply-To: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
Message-ID: <j3JiorbScoe0O2DZezRaE8MmzNQgcOqsfo7t-tc6vkY=.0c68c157-70eb-4e53-a614-283b2ec69374@github.com>

> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
> 
> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.

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

  Add comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3921/files
  - new: https://git.openjdk.java.net/jdk/pull/3921/files/cb9723b7..d46cd678

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

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

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

From akozlov at openjdk.java.net  Tue May 11 16:02:53 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 11 May 2021 16:02:53 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS [v2]
In-Reply-To: <AFQ7ghA-D9kmMyph4MYynW2Qb_57d4uCwbA1q2WrGIo=.c5906aee-3c85-43a7-bd69-f85ab953b2a7@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
 <FQFtXo8OgMcw1Z2rKyezbys7cBKD5zML_unhQVXBBa0=.d9f044e4-f253-4b4e-9fbb-67cfafb99b9f@github.com>
 <AFQ7ghA-D9kmMyph4MYynW2Qb_57d4uCwbA1q2WrGIo=.c5906aee-3c85-43a7-bd69-f85ab953b2a7@github.com>
Message-ID: <tyYVysh3IQX3vC2PX25hxfOuItWq6UrTuBdXau6JiNc=.1905f608-2eb6-44ce-b064-d635fc82d816@github.com>

On Sun, 9 May 2021 09:01:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/prims/universalNativeInvoker.cpp line 35:
>> 
>>> 33: void ProgrammableInvoker::invoke_native(Stub stub, address buff, JavaThread* thread) {
>>> 34:   ThreadToNativeFromVM ttnfvm(thread);
>>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread));
>> 
>> I think we need a comment here, not just in the bug report. if this confused you, it'll surely be enough to confuse a maintainer. Some think like this, perhaps?
>> 
>> `"We need WXExec because we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache. See JDK-8265292."`
>> 
>> I'm also wondering if it would be better to enable writes in the methods that actually write to the nmethod, WDYT?
>
> And incidentally, this seems to be rather error prone. Wouldn't it be simpler to check W^X status in all of the nmethod accessors, and change it when actually required, rather than hoping that it's already in the correct state?

Thanks, I've added the comment here, and also one near VM entries. I would like to avoid enabling write near writing itself. There are too many such places, and either we'll cover a rather large part of hotspot with them (with trial and fix like here, also having overhead from going back and forth), or we'll start clustering them in bigger write-contexts. The current approach is to have the largest write-context possible: the whole JVM should be able to write. Therefore, the bug is not that we didn't get to WXWrite when we are trying to write, the bug is that we were not in the right state. 

Also to @dholmes-ora. Sorry for failing to provide a clear principle in the first place. I really assumed that we were on the same page until reviews of JDK-8262896. Since then I'm preparing a kind of doc, although it's going hard. Thank you for still asking questions :) I'm going to include discussed topics into that doc.

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

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

From rkennke at redhat.com  Tue May 11 17:05:50 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 11 May 2021 19:05:50 +0200
Subject: Timeline for BiasedLocking removal?
In-Reply-To: <c9795241-dce3-59df-f7b5-88ac1068d710@oracle.com>
References: <4aa813a6-c8ce-86ca-d2bd-ba87ea561773@redhat.com>
 <c9795241-dce3-59df-f7b5-88ac1068d710@oracle.com>
Message-ID: <27287501-1523-5fca-d5fa-94b31bca2476@redhat.com>

Good. Does obsoletion mean it can be removed altogether?

If nobody's signed up for it yet, I could also handle the actual removal.

Thanks,
Roman

> JDK-8256425 Obsolete Biased Locking in JDK 18
> https://bugs.openjdk.java.net/browse/JDK-8256425
> 
> On 5/11/21 9:50 AM, Roman Kennke wrote:
>> Hi Hotspot devs,
>>
>> what is the timeline for removing BiasedLocking altogether? Or have we 
>> even agreed that we are going to remove it?
>>
>> I am asking because this affects how I'd move forward with Lilliput. 
>> If I can ignore BiasedLocking because it'd be removed in, say, JDK 18 
>> anyway, then I believe I can come up with a relatively simple 
>> implementation for 64bit header that should be possible to integrate 
>> into JDK 18. That is, I put the (compressed) Klass* in the upper bits 
>> of the header, also keep the hashcode in the header, and keep 
>> everything else (locking, GC bits) as they are.
>>
>> With biased-locking, the Klass* would clash with the Thread* in the 
>> upper bits. If we are not going to remove BiasedLocking anytime soon, 
>> I would have to come up with a different plan.
>>
>> (Also, note that I expect the performance improvement of Lilliput to 
>> outweight possible - and hopefully rare - biased-locking removal 
>> regressions)
>>
>> WDYT?
>>
>> Cheers,
>> Roman
>>
> 


From iklam at openjdk.java.net  Tue May 11 17:12:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 11 May 2021 17:12:23 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <sJyvFHU5KhmFEbzS8UO7tPFY0Koxct_h6PUKvx38hqg=.0de94f46-7bf2-4500-8a26-30fdc83a8cc8@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

The CDS VM and test changes look OK to me.

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65:

> 63:         // so when handling the java mirror for the class we need to make sure its class
> 64:         // loader data is claimed, this is done by calling do_cld explicitly.
> 65:         // For non-string hidden classes the call to do_cld is made when the class

Typo: non-strong

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

Marked as reviewed by iklam (Reviewer).

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

From kbarrett at openjdk.java.net  Tue May 11 17:32:04 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 11 May 2021 17:32:04 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
In-Reply-To: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
Message-ID: <52gUIO5pbwtPTdPeHbKPv5YXDamoPqay47SA6I0VKYU=.85074f28-d9d1-4d2d-bd8e-0f15d7e2baf8@github.com>

On Tue, 11 May 2021 13:06:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
> 
> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
> 
> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
> 
> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
> 
> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
> 
> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).

Changes requested by kbarrett (Reviewer).

src/hotspot/cpu/arm/gc/g1/g1Globals_arm.hpp line 24:

> 22:  */
> 23: 
> 24: #ifndef CPU_AARCH64_GC_G1_G1GLOBALS_ARM_HPP

s/AARCH64/ARM/ in 3 places in this file.  Similar changes in all the other non-aarch64 files.

src/hotspot/share/gc/g1/g1CardTable.hpp line 97:

> 95: 
> 96:   // Mark the given card as Dirty if it is Clean. Returns whether the card has
> 97:   // been Clean before this operation. This result may be inaccurate as it does not

s/card has been Clean/card was Clean/

src/hotspot/share/gc/g1/g1RemSet.cpp line 1071:

> 1069:   static const uint CacheSize = G1MergeHeapRootsPrefetchCacheSize;
> 1070: 
> 1071:   STATIC_ASSERT(is_power_of_2(CacheSize));

Prefer C++11 `static_assert` (with an informative message).

src/hotspot/share/gc/g1/g1RemSet.cpp line 1081:

> 1079: 
> 1080: protected:
> 1081:   // Initial content of all elements in the cache. It's value be "neutral", i.e.

s/value be/value should be/

src/hotspot/share/gc/g1/g1RemSet.cpp line 1084:

> 1082:   // no work done on it.
> 1083:   G1CardTable::CardValue _dummy_card;
> 1084: 

This class should have a protected default destructor.

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

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

From patricio.chilano.mateo at oracle.com  Tue May 11 17:42:15 2021
From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com)
Date: Tue, 11 May 2021 14:42:15 -0300
Subject: Timeline for BiasedLocking removal?
In-Reply-To: <27287501-1523-5fca-d5fa-94b31bca2476@redhat.com>
References: <4aa813a6-c8ce-86ca-d2bd-ba87ea561773@redhat.com>
 <c9795241-dce3-59df-f7b5-88ac1068d710@oracle.com>
 <27287501-1523-5fca-d5fa-94b31bca2476@redhat.com>
Message-ID: <24b4555b-d741-7647-9fc6-56f4822abecd@oracle.com>

Hi Roman,

On 5/11/21 2:05 PM, Roman Kennke wrote:
> Good. Does obsoletion mean it can be removed altogether?
>
> If nobody's signed up for it yet, I could also handle the actual removal.
Yes, obsolete allows code associated with the flag to be removed from 
the codebase 
(https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process).
I plan to remove the code in JDK18 as discussed in 8256253 (I thought I 
was already assigned in the bug).

Thanks,
Patricio
> Thanks,
> Roman
>
>> JDK-8256425 Obsolete Biased Locking in JDK 18
>> https://bugs.openjdk.java.net/browse/JDK-8256425
>>
>> On 5/11/21 9:50 AM, Roman Kennke wrote:
>>> Hi Hotspot devs,
>>>
>>> what is the timeline for removing BiasedLocking altogether? Or have 
>>> we even agreed that we are going to remove it?
>>>
>>> I am asking because this affects how I'd move forward with Lilliput. 
>>> If I can ignore BiasedLocking because it'd be removed in, say, JDK 
>>> 18 anyway, then I believe I can come up with a relatively simple 
>>> implementation for 64bit header that should be possible to integrate 
>>> into JDK 18. That is, I put the (compressed) Klass* in the upper 
>>> bits of the header, also keep the hashcode in the header, and keep 
>>> everything else (locking, GC bits) as they are.
>>>
>>> With biased-locking, the Klass* would clash with the Thread* in the 
>>> upper bits. If we are not going to remove BiasedLocking anytime 
>>> soon, I would have to come up with a different plan.
>>>
>>> (Also, note that I expect the performance improvement of Lilliput to 
>>> outweight possible - and hopefully rare - biased-locking removal 
>>> regressions)
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> Roman
>>>
>>
>


From sspitsyn at openjdk.java.net  Tue May 11 20:27:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 11 May 2021 20:27:54 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
Message-ID: <KDMGAil9kPgYeIGnOeXvG-t_4d7NW2ijw8D-0-I6PrM=.6794313e-501e-408f-80c0-a2ed92e1c3c2@github.com>

On Tue, 11 May 2021 01:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from Serguei

Marked as reviewed by sspitsyn (Reviewer).

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

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

From rkennke at redhat.com  Tue May 11 20:53:29 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 11 May 2021 22:53:29 +0200
Subject: Timeline for BiasedLocking removal?
In-Reply-To: <24b4555b-d741-7647-9fc6-56f4822abecd@oracle.com>
References: <4aa813a6-c8ce-86ca-d2bd-ba87ea561773@redhat.com>
 <c9795241-dce3-59df-f7b5-88ac1068d710@oracle.com>
 <27287501-1523-5fca-d5fa-94b31bca2476@redhat.com>
 <24b4555b-d741-7647-9fc6-56f4822abecd@oracle.com>
Message-ID: <796d9121-1e05-b31b-a3b6-afb268ebef37@redhat.com>

>> Good. Does obsoletion mean it can be removed altogether?
>>
>> If nobody's signed up for it yet, I could also handle the actual removal.
> Yes, obsolete allows code associated with the flag to be removed from 
> the codebase 
> (https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process). 
> 
> I plan to remove the code in JDK18 as discussed in 8256253 (I thought I 
> was already assigned in the bug).

Great!
I will assume in Lilliput that I don't need to worry about BL then, and 
disable it altogether until you remove it:

https://github.com/openjdk/lilliput/pull/4

Thanks,
Roman


From mchung at openjdk.java.net  Tue May 11 20:52:59 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 20:52:59 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53:

> 51:             return simpleName;
> 52:         }
> 53:         // Must be a local class

This file should not be changed.  It refers to the Java language anonymous class (not VM anonymous class).

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

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

From kvn at openjdk.java.net  Tue May 11 21:52:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 11 May 2021 21:52:52 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation [v4]
In-Reply-To: <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>
Message-ID: <ecg7FWWdyjjyv1DTaYP_p0Nizyy0BWun2txsfAisoO8=.0f5814a1-5f90-4cf9-b91b-261c18e8ae35@github.com>

On Mon, 3 May 2021 18:45:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
>> 
>> It served quite well for many years, but it accumulated significant complexity
>> to support different corner cases over time and inevitable evolution of the JVM
>> stretched the whole approach way too much (to the point where it become almost
>> impossible to extend the analysis any further).
>> 
>> It turns out the root problem is the decision to reimplement method resolution
>> and method selection logic from scratch and to perform it on JVM internal
>> representation. It makes it very hard to reason about correctness and the
>> implementation becomes sensitive to changes in internal representation.
>> 
>> So, the main motivation for the redesign is twofold: 
>>  * reduce maintenance burden and increase confidence in the code;
>>  * unlock some long-awaited enhancements.
>> 
>> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
>> any possible enhancements are deliberately kept out of scope for the current PR.
>> (It does deliver a bit of minor enhancements front as the changes in
>> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
>> of the other changes and was not the goal of the current work.)
>> 
>> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
>> and relies on vtable/itable information to detect target method for every
>> subclass it visits. It removes all the complexity associated with method
>> resolution and method selection logic and leaves only essential logic to prepare for method selection.
>> 
>> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
>> Instead of supporting not yet linked case, it is simply ignored. It is safe to
>> skip them (treat as "effectively non-concrete") since it is guaranteed there
>> are no instances created yet. But it requires VM to check dependencies once a
>> class is linked.
>> 
>> I ended up with 2 separate dependency validation passes (when class is loaded
>> and when it is linked). To avoid duplicated work, only dependencies
>> which may be affected by class initialization state change
>> (`unique_concrete_method_4`) are visited. 
>> 
>> (I experimented with merging passes into a single pass (delay the pass until
>> linkage is over), but it severely affected other class-related dependencies and
>> relevant optimizations.code.)
>> 
>> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
>> 
>> Old implementation is kept intact for now (will be removed later) to:
>>   - JVMCI hasn't been migrated to the new implementation yet;
>>   - enable verification that 2 implementations (old and new) agree on the results;
>>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier9
>> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
>> - [x] performance testing
>>   
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover abstract method case

Marked as reviewed by kvn (Reviewer).

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

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

From mchung at openjdk.java.net  Wed May 12 02:50:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 02:50:58 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <SzNTQC13ELzcwsos7x8FHf3u4RkXOGIah31lAUR4sdM=.5e8e2ff4-aa75-42c4-9639-b2e4fba86789@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

I reviewed java.base and took a pass on the test changes.  Here are some comments:
 
test/hotspot/jtreg/runtime/HiddenClasses/TestHiddenClassUnloading.java has this comment:


+// This is based on test compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java


This comment can be removed as this test will be removed.   A few tests under  test/hotspot/jtreg/runtime/HiddenClasses also have similar comment that should be removed.

test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/castToGrandparent/Test.java
test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/classNameInStackTrace/Test.java
- I think these tests are already well covered by test/hotspot/jtreg/runtime/HiddenClasses/CastToParentTest.java
and test/hotspot/jtreg/runtime/HiddenClasses/HiddenClassStack.java 
- I suggest to copy the description from the anonloader tests to these hidden class tests

test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/StressClassLoadingTest.java
   - test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java is a subset of this test.  Should we remove test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java?
   
test/jdk/java/lang/invoke/VMAnonymousClass.java
- FYI.  I have added a new test to verify hidden class (see JDK-8266925)

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

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

From lukenbutters at gmail.com  Wed May 12 04:00:47 2021
From: lukenbutters at gmail.com (Luke B)
Date: Wed, 12 May 2021 14:00:47 +1000
Subject: I have test failures, is master the correct branch to build from?
In-Reply-To: <CAA-vtUwAnBsV3_nnqY_KhxGUr0vVCSqeKSJVN2Y01Z3Lqq_bYA@mail.gmail.com>
References: <CAPYyR4_wm361+-cUh-WSW2qNkBQuhM4BSyxsvxAgZdZruDtoLA@mail.gmail.com>
 <3e6f272d-8dcb-09b9-4d50-8330876ed83d@redhat.com>
 <CAA-vtUwAnBsV3_nnqY_KhxGUr0vVCSqeKSJVN2Y01Z3Lqq_bYA@mail.gmail.com>
Message-ID: <CAPYyR49aPK_Qw+PR60C3y3T-zkgm6oZ45GPHmDBtXOkFAH+2_w@mail.gmail.com>

Hi,

I did not run --with-gtest adding that has resulted in the number of
failures dropping to 1 :D

The failure is in:
serviceability/sa/ClhsdbFindPC.java#id3: Test the clhsdb 'findpc' command
w/o Xcomp on core

Here is a section of the output from the test:

 stdout: [ + findpc 0x00007f3ddfa14548
Address 0x00007f3ddfa14548: In unknown location
];
 stderr: [ + findpc 0x00007f3ddfa14548
Address 0x00007f3ddfa14548: In unknown location
]
 exitValue = -1

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException:
'Address 0x00007f3ddfa14548: .*MaxJNILocalCapacity' missing from
stdout/stderr

	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:283)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:305)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.lang.RuntimeException: 'Address 0x00007f3ddfa14548:
.*MaxJNILocalCapacity' missing from stdout/stderr

	at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:325)
	at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:166)
	at ClhsdbLauncher.runOnCore(ClhsdbLauncher.java:225)
	at ClhsdbFindPC.runTest(ClhsdbFindPC.java:295)
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:278)
	... 7 more

JavaTest Message: Test threw exception: java.lang.RuntimeException:
Test ERROR java.lang.RuntimeException: 'Address 0x00007f3ddfa14548:
.*MaxJNILocalCapacity' missing from stdout/stderr

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test
ERROR java.lang.RuntimeException: 'Address 0x00007f3ddfa14548:
.*MaxJNILocalCapacity' missing from stdout/stderr

The complete output is available at: https://pastebin.com/kz7DsHZU

many thanks,

Luke

On Tue, May 11, 2021 at 9:24 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

>
> On Tue, May 11, 2021 at 11:06 AM Aleksey Shipilev <shade at redhat.com>
> wrote:
>
>> On 5/11/21 11:00 AM, Luke B wrote:
>> > Looking in the report.html for the hotspot tests I see:
>> > "native" failed 7 tests and "bug8251158 native" failed 2 tests.
>>
>> Please show the *names* of the failing tests, i.e. their file paths. And
>> the gist of the failing
>> test output (i.e. console output of "make run-test-tier1").
>>
>> "bug8251158" suggests these are gtest tests?
>>
>> $ ack 8251158 test/
>> test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java
>> 28: * @bug 8251158
>> 46: * @bug 8251158
>>
>> test/hotspot/jtreg/gtest/MetaspaceGtests.java
>> 33: * @bug 8251158
>> 44: * @bug 8251158
>> 57: * @bug 8251158
>> 68: * @bug 8251158
>>
>> So this might suggest you have a problem with google-test. tier1 passes
>> well with
>> googletest-release-1.8.1 for me.
>>
>>
> @Luke: did you build with --with-gtest? That is needed for these tests.
>
> Cheers, Thomas
>
>
>> > Is this expected, am I building the wrong branch? If not do I need to
>> > install something to get those tests passing?
>>
>> tier1 is supposed to pass everywhere.
>>
>> > Should I be applying a ProblemList.txt, if so which one and how should
>> that
>> > be run? Perhaps I need to call jtreg directly rather than via make?
>>
>> jtreg would hook up the default ProblemList.txt itself, you don't need to
>> do anything else.
>>
>> --
>> Thanks,
>> -Aleksey
>>
>>

From ddong at openjdk.java.net  Wed May 12 05:31:46 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 12 May 2021 05:31:46 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v4]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <CSHp8znqkPBWv-ZYnzs7F5pwYjeGBvXaIlrAC3sFuRY=.9817e320-9658-492e-829a-eb7063fe774b@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

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

  comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/82d8cc6c..6a089b24

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

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

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

From david.holmes at oracle.com  Wed May 12 06:58:16 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 May 2021 16:58:16 +1000
Subject: I have test failures, is master the correct branch to build from?
In-Reply-To: <CAPYyR49aPK_Qw+PR60C3y3T-zkgm6oZ45GPHmDBtXOkFAH+2_w@mail.gmail.com>
References: <CAPYyR4_wm361+-cUh-WSW2qNkBQuhM4BSyxsvxAgZdZruDtoLA@mail.gmail.com>
 <3e6f272d-8dcb-09b9-4d50-8330876ed83d@redhat.com>
 <CAA-vtUwAnBsV3_nnqY_KhxGUr0vVCSqeKSJVN2Y01Z3Lqq_bYA@mail.gmail.com>
 <CAPYyR49aPK_Qw+PR60C3y3T-zkgm6oZ45GPHmDBtXOkFAH+2_w@mail.gmail.com>
Message-ID: <41bf2575-5c42-fa20-2974-26c98cbc77a6@oracle.com>

Hi Luke,

On 12/05/2021 2:00 pm, Luke B wrote:
> Hi,
> 
> I did not run --with-gtest adding that has resulted in the number of
> failures dropping to 1 :D

Good result!

> The failure is in:
> serviceability/sa/ClhsdbFindPC.java#id3: Test the clhsdb 'findpc' command
> w/o Xcomp on core

Known issue. Test fails intermittently on some Linuxes:

https://bugs.openjdk.java.net/browse/JDK-8263242

Cheers,
David
-----

> Here is a section of the output from the test:
> 
>   stdout: [ + findpc 0x00007f3ddfa14548
> Address 0x00007f3ddfa14548: In unknown location
> ];
>   stderr: [ + findpc 0x00007f3ddfa14548
> Address 0x00007f3ddfa14548: In unknown location
> ]
>   exitValue = -1
> 
> java.lang.RuntimeException: Test ERROR java.lang.RuntimeException:
> 'Address 0x00007f3ddfa14548: .*MaxJNILocalCapacity' missing from
> stdout/stderr
> 
> 	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:283)
> 	at ClhsdbFindPC.main(ClhsdbFindPC.java:305)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> Caused by: java.lang.RuntimeException: 'Address 0x00007f3ddfa14548:
> .*MaxJNILocalCapacity' missing from stdout/stderr
> 
> 	at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:325)
> 	at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:166)
> 	at ClhsdbLauncher.runOnCore(ClhsdbLauncher.java:225)
> 	at ClhsdbFindPC.runTest(ClhsdbFindPC.java:295)
> 	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:278)
> 	... 7 more
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException:
> Test ERROR java.lang.RuntimeException: 'Address 0x00007f3ddfa14548:
> .*MaxJNILocalCapacity' missing from stdout/stderr
> 
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test
> ERROR java.lang.RuntimeException: 'Address 0x00007f3ddfa14548:
> .*MaxJNILocalCapacity' missing from stdout/stderr
> 
> The complete output is available at: https://pastebin.com/kz7DsHZU
> 
> many thanks,
> 
> Luke
> 
> On Tue, May 11, 2021 at 9:24 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> 
>>
>> On Tue, May 11, 2021 at 11:06 AM Aleksey Shipilev <shade at redhat.com>
>> wrote:
>>
>>> On 5/11/21 11:00 AM, Luke B wrote:
>>>> Looking in the report.html for the hotspot tests I see:
>>>> "native" failed 7 tests and "bug8251158 native" failed 2 tests.
>>>
>>> Please show the *names* of the failing tests, i.e. their file paths. And
>>> the gist of the failing
>>> test output (i.e. console output of "make run-test-tier1").
>>>
>>> "bug8251158" suggests these are gtest tests?
>>>
>>> $ ack 8251158 test/
>>> test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java
>>> 28: * @bug 8251158
>>> 46: * @bug 8251158
>>>
>>> test/hotspot/jtreg/gtest/MetaspaceGtests.java
>>> 33: * @bug 8251158
>>> 44: * @bug 8251158
>>> 57: * @bug 8251158
>>> 68: * @bug 8251158
>>>
>>> So this might suggest you have a problem with google-test. tier1 passes
>>> well with
>>> googletest-release-1.8.1 for me.
>>>
>>>
>> @Luke: did you build with --with-gtest? That is needed for these tests.
>>
>> Cheers, Thomas
>>
>>
>>>> Is this expected, am I building the wrong branch? If not do I need to
>>>> install something to get those tests passing?
>>>
>>> tier1 is supposed to pass everywhere.
>>>
>>>> Should I be applying a ProblemList.txt, if so which one and how should
>>> that
>>>> be run? Perhaps I need to call jtreg directly rather than via make?
>>>
>>> jtreg would hook up the default ProblemList.txt itself, you don't need to
>>> do anything else.
>>>
>>> --
>>> Thanks,
>>> -Aleksey
>>>
>>>

From xliu at openjdk.java.net  Wed May 12 07:06:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 12 May 2021 07:06:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <qDE2NmiV31vp9uylkUpQEBHCwJtnSjFA_q947V41RX0=.6848a39b-61cc-4e01-add6-ecf12d9fb9d3@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
 <7NSek1vJKe2IhUCPtObalVJqfjczfkD9KrgrTvtlROc=.523f6b98-149c-4307-ae13-bfb315b62f7f@github.com>
 <qDE2NmiV31vp9uylkUpQEBHCwJtnSjFA_q947V41RX0=.6848a39b-61cc-4e01-add6-ecf12d9fb9d3@github.com>
Message-ID: <JO1gHZ_P80NmzdLlK6p4sQKZtw6nsNJRcHde2gmAs5g=.20335359-ba08-4031-8868-69ad41de29b2@github.com>

On Fri, 7 May 2021 06:56:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yes, it is for the statistics of dropped messages.
>> 
>> AsyncLogMap looks a little cumbersome indeed, but the good side is that I isolate async logging things in logAsyncFlusher.hpp/cpp.  I manage not to pollute shared unified logging code. 
>> 
>> Another reason is that I can deliver the zero-cost promise when async logging is off.  If I move the counter to LogFileOutput, it will increase those object size a little bit.  In current implementation,  the singleton object LogAsyncFlusher is not created if -Xlog:async is absent.
>> 
>> Size wise, I think it's okay to to have 8 byte.  if a network-based device disappeared, who know how long asynclog thread  would block.  bigger counter is better.  Cost is almost same because the number of logFileOutput objects is usually less than 4.
>
> I respect your "no costs promise" concern, but really this is no problem. We create exactly one LogFileOutput object per file sink; so usually we have one, maybe two of those if async=true. I think the costs of those counters would be bearable :)
> 
> I understand the concern of not polluting the UL code base. But here I think it does not apply, since you bring your patch upstream anyway, so async logging is now part of the UL code base.
> 
> wrt to counter size, okay lets use 64bit. But lets really use 64bit, also in 32bit VMs (so, use uint64_t instead of uintx).

Hi, @tstuefe , 
I agree with you that uintx is not a good type. uint32_t is big enough. 

I found it's  very tricky to move those counters to LogFileOutput objects. after than, I still need HashTable as a set to traverse all LogFileObject objects. 

Alternatively, there's a member variable `_outputs` in LogConfiguration, which refers to all LogOutput objects. I have to obtain  `ConfigurationLock` first before reading it because jcmd could modify outputs at any moment.  Grabbing `ConfigurationLock`  in `LogAsyncFlusher::flush` may lead to a dead lock with `_lock`.  This part of code is really subtle. I tried different approaches. no one is  more straight-forward than a hashmap.

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

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

From tschatzl at openjdk.java.net  Wed May 12 07:45:36 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 12 May 2021 07:45:36 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v2]
In-Reply-To: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
Message-ID: <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>

> Hi all,
> 
>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
> 
> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
> 
> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
> 
> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
> 
> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
> 
> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).

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

  kbarrett review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3975/files
  - new: https://git.openjdk.java.net/jdk/pull/3975/files/9a1d8ef9..288ba6dc

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

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

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

From xxinliu at amazon.com  Wed May 12 07:55:45 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 12 May 2021 00:55:45 -0700
Subject: Request For Comment: Asynchronous Logging
In-Reply-To: <CAA-vtUz+1ia9tno=ORt9zj8bFV=LZObQZ+DLu9b530caDkTzng@mail.gmail.com>
References: <CA+3eh11dvq7yR9QVFES6J-g3m=59ORrUuAMRj0XEcuURF_x_iA@mail.gmail.com>
 <a6da0515-3f58-4642-fa37-6374383f138f@amazon.com>
 <CAA-vtUz+1ia9tno=ORt9zj8bFV=LZObQZ+DLu9b530caDkTzng@mail.gmail.com>
Message-ID: <0d6f2077-8960-8bdc-2eed-1ad42355f4b6@amazon.com>

hi, Thomas,

Thank you for your reasoning. Your arguments are convincing.

I have updated the CSR description.  No matter what, dropping the
incoming message is trivial. let's keep thing simple.

Can we finalize the CSR?

thanks,
--lx



On 5/11/21 3:08 AM, Thomas St?fe wrote:
> *CAUTION*: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
> 
> 
> Hi Xin, see my answer in the CSR.
> 
> Cheers, Thomas
> 
> On Tue, May 11, 2021 at 9:53 AM Liu, Xin <xxinliu at amazon.com
> <mailto:xxinliu at amazon.com>> wrote:
> 
>     Hi,
> 
>     This RFC covers almost all aspects of async logging. Since then, we have
>     drawn many consensus and implemented them one by one.
> 
>     I still have one open question. What's the discard policy?
> 
>     Problem statement:
>     For async-logging, we proposed a lossy non-blocking design. that is to
>     say, the buffer is bounded and we have to drop messages for
>     non-blocking. The rationale was described: here:
>     https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487
>     <https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487>
> 
>     The discard policy defines which message is dropped at logsite when the
>     buffer is full. There're at least 3 choices.
>     1. drop the oldest message and proceed to enqueue.
>     2. give up enqueue attempt. that is to say, the newest message is
>     discarded.
>     3. support them both, let user to choose.
> 
>     It seems different data structures of buffer bias to different discard
>     policy. eg. printk of Linux kernel uses a fixed ringbuffer. It chooses
>     1) because that is naturally done by ringbuffer overwrite.
> 
>     Folly logging library also supports async writing. They chose 2) because
>     it's straight-forward for a bounded array.
>     https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91
>     <https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91>
> 
>     My current implementation is just in the middle two polar opinions. my
>     buffer is implemented using a linkedlist-based deque. It means that I
>     can pop elements from either sides. technically speaking, I can easily
>     support 2 discard policies.
> 
>     In CSR, I wrote the following sentence in Solution section.
>     "On buffer exhaustion a message is discarded so that under no
>     circumstances will logging block threads. Which message is discarded
>     depends on implementation. In current implementation, the oldest message
>     is discarded to make room for the newest message. "
> 
>     The reason I would like to "leave to implementation" because I don't
>     think it's a good idea to choose a discard policy in CSR. The wiggle
>     room can give more freedom for changing different data structures and
>     algorithms. David said we can't it undefined. If so, what's the discard
>     policy HotSpot prefers?
> 
>     We have discussed it on CSR.
>     https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683
>     <https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683>
> 
>     There are more audiences. Inputs are welcome.
> 
>     FYI, current PR#3135 has implemented dropped message statistics. In the
>     log files, you would find meta messages to indicate how many messages
>     were lost. eg. line @34300:
>     34299-[trace][metaspace? ? ? ? ? ? ? ] Metaspace::allocate: type 7
>     return 0x00007fcf284fcb18.
>     34300:[warning][? ? ? ? ? ? ? ? ? ? ? ?]? ? 529 messages dropped...
>     34301-[trace? ][metaspace? ? ? ? ? ? ? ] Arena @0x00007fcf80252df0
>     (non-class sm): after allocation: 1 chunk(s),
>     current:@0x00007fcf80243ef0, u, base 0x00007fcf28400000, level lv00
>     (524288), used: 132162, committed: 139264, committed-free: 7102
> 
>     thanks,
>     --lx
> 
> 
> 
>     On 3/30/21 11:18 AM, Volker Simonis wrote:
>     > CAUTION: This email originated from outside of the organization.
>     Do not click links or open attachments unless you can confirm the
>     sender and know the content is safe.
>     >
>     >
>     >
>     > Hi,
>     >
>     > I'd like to (re)start a discussion on asynchronous logging [1,2,3,4].
>     > We are successfully using this feature productively at Amazon both in
>     > jdk8 and jdk11 to reduce the tail latency of services which use
>     > logging. We think that async logging is a useful addition to the
>     > current logging framework which might be beneficial to a wider range
>     > of users. The following write-up tries to capture the comments and
>     > suggestions from the previous discussions we are aware of.
>     >
>     > Current state:
>     >
>     > - HotSpot uses the so called "Unified Logging" (UL) framework which
>     > was introduced by JEP 158 [5] in JDK 9. Most logs have been
>     > retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging"
>     > [6]).
>     > - The current UL implementation is based on the standard C buffered
>     > stream I/O interface [7]. The LogFileStreamOutput class which writes
>     > logs to abstract FILE streams is the only child of the abstract base
>     > class LogOutput. LogFileStreamOutput has three child classes
>     > LogStdoutOutput,? LogStderrOutput and LogFileOutput which write to
>     > stdout, stderr or an arbitrary file respectively. The initial UL JEP
>     > 158 [5] envisioned logging to a socket but has not implemented it. At
>     > least one such extension has been proposed since then [8].
>     > - UL synchronizes logs from different threads with the help of the
>     > standard C flockfile()/funlockfile() [9] functions. But even without
>     > this explicit locking, all the "stdio functions are thread-safe. This
>     > is achieved by assigning to each FILE object a lockcount and (if the
>     > lockcount is nonzero) an owning thread.? For each library call, these
>     > functions wait until the FILE object is no longer locked by a
>     > different thread, then lock it, do the requested I/O, and unlock the
>     > object again" [9]. A quick look at the glibc sources reveals that FILE
>     > locking is implemented with the help of futex() [10] which breaks down
>     > to s simple atomic compare and swap (CAS) on the fast path.
>     > - Notice that UL "synchronizes" logs from different threads to avoid
>     > log interleaving. But it does not "serialize" logs according to the
>     > time at which? they occurred. This is because the underlying stdio
>     > functions do not guarantee a specific order for different threads
>     > waiting on a locked FILE stream. E.g. if three log events A, B, C
>     > occur in that order, the first will lock the output stream. If the log
>     > events B and C both arrive while the stream is locked, it is
>     > unspecified which of B and C will be logged first after A releases the
>     > lock.
>     >
>     > Problem statement:
>     >
>     > - The amount of time a log event will block its FILE stream depends on
>     > the underlying file system. This can range from a few nanoseconds for
>     > in-memory file systems or milliseconds for physical discs under heavy
>     > load up to several seconds in the worst case scenario for e.g. network
>     > file systems. A blocked log output stream will block all concurrent
>     > threads which try to write log messages at the same time. If logging
>     > is done during a safepoint, this can significantly increase the
>     > safepoint time (e.g. several parallel GC threads trying to log at the
>     > same time). We can treat stdout/stderr as special files here without
>     > loss of generality.
>     >
>     > Proposed solution:
>     >
>     > Extend UL with an asynchronous logging facility. Asynchronous logging
>     > will be optional and disabled by default. It should have the following
>     > properties:
>     > - If disabled (the default) asynchronous logging should have no
>     > observable impact on logging.
>     > - If enabled, log messages will be stored in an intermediate data
>     > structure (e.g. a double ended queue).
>     > - A service thread will concurrently read and remove log messages from
>     > that data structure in a FIFO style and write them to the output
>     > stream
>     > - Storing log messages in the intermediate data structure should take
>     > constant time and not longer than logging a message takes in the
>     > traditional UL system (in general the time should be much shorter
>     > because the actual I/O is deferred).
>     > - Asynchronous logging trades memory overhead (i.e. the size of the
>     > intermediate data structure) for log accuracy. This means that in the
>     > unlikely case where the service thread which does the asynchronous
>     > logging falls behind the log producing threads, some logs might be
>     > lost. However, the probability for this to happen can be minimized by
>     > increasing the configurable size of the intermediate data structure.
>     > - The final output produced by asynchronous logging should be equal to
>     > the output from normal logging if no messages had to be dropped.
>     > Notice that in contrast to the traditional unified logging,
>     > asynchronous logging will give us the possibility to not only
>     > synchronize log events, but to optionally also serialize them based on
>     > their generation time if that's desired. This is because we are in
>     > full control of the synchronization primitives for the intermediate
>     > data structure which stores the logs.
>     > - If log messages had to be dropped, this should be logged in the log
>     > output (e.g. "[..] 42 messages dropped due to async logging")
>     > - Asynchronous logging should ideally be implemented in such a way
>     > that it can be easily adapted by alternative log targets like for
>     > example sockets in the future.
>     >
>     > Alternative solutions:
>     > - It has repeatedly been suggested to place the log files into a
>     > memory file system but we don't think this is an optimal solution.
>     > Main memory is often a constrained resource and we don't want log
>     > files to compete with the JVM for it in such cases.
>     > - It has also been argued to place the log files on a fast file system
>     > which is only used for logging but in containerized environments file
>     > system are often virtualized and the properties of the underlying
>     > physical devices are not obvious.
>     > - The load on the file system might be unpredictable due to other
>     > applications on the same host.
>     > - All these workarounds won't work if we eventually implement direct
>     > logging to a network socket as suggested in [8].
>     >
>     > Implementation details / POC:
>     >
>     > - A recent pull request [2] for JDK-8229517 [3] proposed to use a
>     > simple deque implementation derived from HotSpot's LinkedListImpl
>     > class for the intermediate data structure. It synchronizes access to
>     > the queue with a MutexLocker which is internally implemented with
>     > pthread_lock() and results in an atomic CAS on the fast path. So
>     > performance-wise the locking itself is not different from the
>     > flockfile()/funlockfile() functionality currently used by UL but
>     > adding a log message to the deque should be constant as it basically
>     > only requires a strdup(). And we could even eliminate the strdup() if
>     > we'd pre-allocate a big enough array for holding the log messages as
>     > proposed in the pull request [2].
>     > - The pull pull request [2] for JDK-8229517 [3] proposed to set the
>     > async flag as an attribute of the Xlog option which feels more natural
>     > because UL configuration is traditionally done within the Xlog option.
>     > But we could just as well use a global -XX flag to enable async
>     > logging? What are your preferences here?
>     > - The pull pull request [2] for JDK-8229517 [3] (mis)uses the
>     > WatcherThread as service thread to concurrently process the
>     > intermediate data structure and write the log messages out to the log
>     > stream. That should definitely be changed to an independent service
>     > thread.
>     > - The pull pull request [2] for JDK-8229517 [3] initially proposed
>     > that the "service thread" runs at a fixed interval to dump log
>     > messages to the log streams. But reviewers commented that this should
>     > better happen either continuously or based on the filling level of the
>     > intermediate data structure. What are your preferences here?
>     > - What are your preferences on the configuration of the intermediate
>     > data structure? Should it be configured based on the maximum number of
>     > log messages it can store or rather on the total size of the stored
>     > log messages? I think that for normal runs this distinction probably
>     > won't make a big difference because the size of log messages will
>     > probably be the same on average so "number of log messages" should
>     > always be proportional to "total size of log mesages".
>     >
>     > 1. Before diving into more implementation details, I'd first like to
>     > reach a general consensus that asynchronous logging is a useful
>     > feature that's worth while adding to HotSpot.
>     >
>     > 2. Once we agree on that, we should agree on the desired properties of
>     > asynchronous logging. I've tried to collect a basic set in the
>     > "Proposed solution" section.
>     >
>     > 3. If that's done as well, we can discuss various implementation
>     > details and finally prepare new pull requests.
>     >
>     > Thank you and best regards,
>     > Volker
>     >
>     > [1] https://bugs.openjdk.java.net/browse/JDK-8229517
>     <https://bugs.openjdk.java.net/browse/JDK-8229517>
>     > [2] https://github.com/openjdk/jdk/pull/3135
>     <https://github.com/openjdk/jdk/pull/3135>
>     > [3]
>     https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
>     <https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html>
>     > [4]
>     https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
>     <https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html>
>     > [5] https://openjdk.java.net/jeps/158
>     <https://openjdk.java.net/jeps/158>
>     > [6] https://openjdk.java.net/jeps/271
>     <https://openjdk.java.net/jeps/271>
>     > [7] https://man7.org/linux/man-pages/man3/stdio.3.html
>     <https://man7.org/linux/man-pages/man3/stdio.3.html>
>     > [8]
>     https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d
>     <https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d>
>     > [9] https://man7.org/linux/man-pages/man3/flockfile.3.html
>     <https://man7.org/linux/man-pages/man3/flockfile.3.html>
>     > [10] https://man7.org/linux/man-pages/man2/futex.2.html
>     <https://man7.org/linux/man-pages/man2/futex.2.html>
>     >
> 

From tschatzl at openjdk.java.net  Wed May 12 08:00:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 12 May 2021 08:00:59 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v2]
In-Reply-To: <52gUIO5pbwtPTdPeHbKPv5YXDamoPqay47SA6I0VKYU=.85074f28-d9d1-4d2d-bd8e-0f15d7e2baf8@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
 <52gUIO5pbwtPTdPeHbKPv5YXDamoPqay47SA6I0VKYU=.85074f28-d9d1-4d2d-bd8e-0f15d7e2baf8@github.com>
Message-ID: <4h_moitRcN4NoRpawPH_SyeiqBms0UUMkYgD87xm6qQ=.2a2c698a-1e6b-491d-ab10-8e4693c16c6d@github.com>

On Tue, 11 May 2021 17:01:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett review
>
> src/hotspot/cpu/arm/gc/g1/g1Globals_arm.hpp line 24:
> 
>> 22:  */
>> 23: 
>> 24: #ifndef CPU_AARCH64_GC_G1_G1GLOBALS_ARM_HPP
> 
> s/AARCH64/ARM/ in 3 places in this file.  Similar changes in all the other non-aarch64 files.

Sorry, copy&paste :(

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

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

From xliu at openjdk.java.net  Wed May 12 08:02:46 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 12 May 2021 08:02:46 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v13]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <bak9ne-zZH7gzi5NXHoEFCm6M9Hw2fSK5iCha2w5CJw=.f6ccbc5b-8977-43e3-8598-37903b63687d@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Update based on the feedbacks from reviwers.
   
   Since I have incorporated in JDK-8266503, store LogDecoration by value in
   AsyncLogMessage.
   Remove AsyncLogMessage::destroy()
   change dropped message counters to uint32_t.
   Add more comments.
 - Merge branch 'master' into JDK-8229517
 - Change option AsyncLogBufferEntries to AsyncLogBufferSize.
   
   AsyncLogBufferSize is the memory budget in bytes for Asynchronous Logging.
   User can specify it in shorthand form. eg. -XX:AsyncLogBufferSize=10M.
 - Use LogTagSetMapping<LogTag::__NO_TAG>::tagset() instead of NULL pointer.
 - Implement the global option -Xlog:async per CSR.
   
   The old options -XX:+AsyncLogging and the output option are both removed.
   This patch also deliver the zero-cost promise. ie. No AsyncLog thread will be
   launched if async_mode is not eanbled.
 - Reimplement Accurate Decorations for AsyncLogging.
   
   LogDecorations defines a copy constructutor. Each log message copys it
   once.
 - Revert "Accurate Decorations for AsyncLogging."
   
   This reverts commit 1f06be3126f829055aff3720aea7e82544fd0c3a.
 - Fix bugs/style/typo based on reviewers' feedbacks.
 - Accurate Decorations for AsyncLogging.
   
   A lightweight LogDecorationRef is created to keep LogDecorations at
   logging site. It uses refcnt to keep track multiple usage and
   automatically clean up. If no decorator is in use, no LogDecorationRef
   is created.
 - Refactor LogAsyncFlusher::abort()
   
   This change makes sure LogAsyncFlusher::abort() is lock-less.
   Therefore, it's not subject to mutex rank issue. Newly added
   gtest(mutex_lock_access_leaf)  may deliberately trigger SIGSEGV
   while holding access rank mutex, so abort() must be lockless.
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/04fad704...908d2a36

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

Changes: https://git.openjdk.java.net/jdk/pull/3135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=12
  Stats: 735 lines in 22 files changed: 721 ins; 5 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

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

From thomas.stuefe at gmail.com  Wed May 12 08:29:43 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 12 May 2021 10:29:43 +0200
Subject: Request For Comment: Asynchronous Logging
In-Reply-To: <0d6f2077-8960-8bdc-2eed-1ad42355f4b6@amazon.com>
References: <CA+3eh11dvq7yR9QVFES6J-g3m=59ORrUuAMRj0XEcuURF_x_iA@mail.gmail.com>
 <a6da0515-3f58-4642-fa37-6374383f138f@amazon.com>
 <CAA-vtUz+1ia9tno=ORt9zj8bFV=LZObQZ+DLu9b530caDkTzng@mail.gmail.com>
 <0d6f2077-8960-8bdc-2eed-1ad42355f4b6@amazon.com>
Message-ID: <CAA-vtUyoJuMEZUPWsQXA_rW8mH=Rz2LO_HxMs+ndH_4GPJgCAQ@mail.gmail.com>

>
>
>
I can't. I believe finalization can only be done by Joe Darcy? Not
sure. @David?

..Thomas

On Wed, May 12, 2021 at 9:55 AM Liu, Xin <xxinliu at amazon.com> wrote:

> hi, Thomas,
>
> Thank you for your reasoning. Your arguments are convincing.
>
> I have updated the CSR description.  No matter what, dropping the
> incoming message is trivial. let's keep thing simple.
>
> Can we finalize the CSR?
>
thanks,
> --lx
>
>
>
> On 5/11/21 3:08 AM, Thomas St?fe wrote:
> > *CAUTION*: This email originated from outside of the organization. Do
> > not click links or open attachments unless you can confirm the sender
> > and know the content is safe.
> >
> >
> > Hi Xin, see my answer in the CSR.
> >
> > Cheers, Thomas
> >
> > On Tue, May 11, 2021 at 9:53 AM Liu, Xin <xxinliu at amazon.com
> > <mailto:xxinliu at amazon.com>> wrote:
> >
> >     Hi,
> >
> >     This RFC covers almost all aspects of async logging. Since then, we
> have
> >     drawn many consensus and implemented them one by one.
> >
> >     I still have one open question. What's the discard policy?
> >
> >     Problem statement:
> >     For async-logging, we proposed a lossy non-blocking design. that is
> to
> >     say, the buffer is bounded and we have to drop messages for
> >     non-blocking. The rationale was described: here:
> >     https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487
> >     <https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487>
> >
> >     The discard policy defines which message is dropped at logsite when
> the
> >     buffer is full. There're at least 3 choices.
> >     1. drop the oldest message and proceed to enqueue.
> >     2. give up enqueue attempt. that is to say, the newest message is
> >     discarded.
> >     3. support them both, let user to choose.
> >
> >     It seems different data structures of buffer bias to different
> discard
> >     policy. eg. printk of Linux kernel uses a fixed ringbuffer. It
> chooses
> >     1) because that is naturally done by ringbuffer overwrite.
> >
> >     Folly logging library also supports async writing. They chose 2)
> because
> >     it's straight-forward for a bounded array.
> >
> https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91
> >     <
> https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91
> >
> >
> >     My current implementation is just in the middle two polar opinions.
> my
> >     buffer is implemented using a linkedlist-based deque. It means that I
> >     can pop elements from either sides. technically speaking, I can
> easily
> >     support 2 discard policies.
> >
> >     In CSR, I wrote the following sentence in Solution section.
> >     "On buffer exhaustion a message is discarded so that under no
> >     circumstances will logging block threads. Which message is discarded
> >     depends on implementation. In current implementation, the oldest
> message
> >     is discarded to make room for the newest message. "
> >
> >     The reason I would like to "leave to implementation" because I don't
> >     think it's a good idea to choose a discard policy in CSR. The wiggle
> >     room can give more freedom for changing different data structures and
> >     algorithms. David said we can't it undefined. If so, what's the
> discard
> >     policy HotSpot prefers?
> >
> >     We have discussed it on CSR.
> >
> https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683
> >     <
> https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683
> >
> >
> >     There are more audiences. Inputs are welcome.
> >
> >     FYI, current PR#3135 has implemented dropped message statistics. In
> the
> >     log files, you would find meta messages to indicate how many messages
> >     were lost. eg. line @34300:
> >     34299-[trace][metaspace              ] Metaspace::allocate: type 7
> >     return 0x00007fcf284fcb18.
> >     34300:[warning][                       ]    529 messages dropped...
> >     34301-[trace  ][metaspace              ] Arena @0x00007fcf80252df0
> >     (non-class sm): after allocation: 1 chunk(s),
> >     current:@0x00007fcf80243ef0, u, base 0x00007fcf28400000, level lv00
> >     (524288), used: 132162, committed: 139264, committed-free: 7102
> >
> >     thanks,
> >     --lx
> >
> >
> >
> >     On 3/30/21 11:18 AM, Volker Simonis wrote:
> >     > CAUTION: This email originated from outside of the organization.
> >     Do not click links or open attachments unless you can confirm the
> >     sender and know the content is safe.
> >     >
> >     >
> >     >
> >     > Hi,
> >     >
> >     > I'd like to (re)start a discussion on asynchronous logging
> [1,2,3,4].
> >     > We are successfully using this feature productively at Amazon both
> in
> >     > jdk8 and jdk11 to reduce the tail latency of services which use
> >     > logging. We think that async logging is a useful addition to the
> >     > current logging framework which might be beneficial to a wider
> range
> >     > of users. The following write-up tries to capture the comments and
> >     > suggestions from the previous discussions we are aware of.
> >     >
> >     > Current state:
> >     >
> >     > - HotSpot uses the so called "Unified Logging" (UL) framework which
> >     > was introduced by JEP 158 [5] in JDK 9. Most logs have been
> >     > retrofitted to use UL since then (e.g. "JEP 271: Unified GC
> Logging"
> >     > [6]).
> >     > - The current UL implementation is based on the standard C buffered
> >     > stream I/O interface [7]. The LogFileStreamOutput class which
> writes
> >     > logs to abstract FILE streams is the only child of the abstract
> base
> >     > class LogOutput. LogFileStreamOutput has three child classes
> >     > LogStdoutOutput,  LogStderrOutput and LogFileOutput which write to
> >     > stdout, stderr or an arbitrary file respectively. The initial UL
> JEP
> >     > 158 [5] envisioned logging to a socket but has not implemented it.
> At
> >     > least one such extension has been proposed since then [8].
> >     > - UL synchronizes logs from different threads with the help of the
> >     > standard C flockfile()/funlockfile() [9] functions. But even
> without
> >     > this explicit locking, all the "stdio functions are thread-safe.
> This
> >     > is achieved by assigning to each FILE object a lockcount and (if
> the
> >     > lockcount is nonzero) an owning thread.  For each library call,
> these
> >     > functions wait until the FILE object is no longer locked by a
> >     > different thread, then lock it, do the requested I/O, and unlock
> the
> >     > object again" [9]. A quick look at the glibc sources reveals that
> FILE
> >     > locking is implemented with the help of futex() [10] which breaks
> down
> >     > to s simple atomic compare and swap (CAS) on the fast path.
> >     > - Notice that UL "synchronizes" logs from different threads to
> avoid
> >     > log interleaving. But it does not "serialize" logs according to the
> >     > time at which  they occurred. This is because the underlying stdio
> >     > functions do not guarantee a specific order for different threads
> >     > waiting on a locked FILE stream. E.g. if three log events A, B, C
> >     > occur in that order, the first will lock the output stream. If the
> log
> >     > events B and C both arrive while the stream is locked, it is
> >     > unspecified which of B and C will be logged first after A releases
> the
> >     > lock.
> >     >
> >     > Problem statement:
> >     >
> >     > - The amount of time a log event will block its FILE stream
> depends on
> >     > the underlying file system. This can range from a few nanoseconds
> for
> >     > in-memory file systems or milliseconds for physical discs under
> heavy
> >     > load up to several seconds in the worst case scenario for e.g.
> network
> >     > file systems. A blocked log output stream will block all concurrent
> >     > threads which try to write log messages at the same time. If
> logging
> >     > is done during a safepoint, this can significantly increase the
> >     > safepoint time (e.g. several parallel GC threads trying to log at
> the
> >     > same time). We can treat stdout/stderr as special files here
> without
> >     > loss of generality.
> >     >
> >     > Proposed solution:
> >     >
> >     > Extend UL with an asynchronous logging facility. Asynchronous
> logging
> >     > will be optional and disabled by default. It should have the
> following
> >     > properties:
> >     > - If disabled (the default) asynchronous logging should have no
> >     > observable impact on logging.
> >     > - If enabled, log messages will be stored in an intermediate data
> >     > structure (e.g. a double ended queue).
> >     > - A service thread will concurrently read and remove log messages
> from
> >     > that data structure in a FIFO style and write them to the output
> >     > stream
> >     > - Storing log messages in the intermediate data structure should
> take
> >     > constant time and not longer than logging a message takes in the
> >     > traditional UL system (in general the time should be much shorter
> >     > because the actual I/O is deferred).
> >     > - Asynchronous logging trades memory overhead (i.e. the size of the
> >     > intermediate data structure) for log accuracy. This means that in
> the
> >     > unlikely case where the service thread which does the asynchronous
> >     > logging falls behind the log producing threads, some logs might be
> >     > lost. However, the probability for this to happen can be minimized
> by
> >     > increasing the configurable size of the intermediate data
> structure.
> >     > - The final output produced by asynchronous logging should be
> equal to
> >     > the output from normal logging if no messages had to be dropped.
> >     > Notice that in contrast to the traditional unified logging,
> >     > asynchronous logging will give us the possibility to not only
> >     > synchronize log events, but to optionally also serialize them
> based on
> >     > their generation time if that's desired. This is because we are in
> >     > full control of the synchronization primitives for the intermediate
> >     > data structure which stores the logs.
> >     > - If log messages had to be dropped, this should be logged in the
> log
> >     > output (e.g. "[..] 42 messages dropped due to async logging")
> >     > - Asynchronous logging should ideally be implemented in such a way
> >     > that it can be easily adapted by alternative log targets like for
> >     > example sockets in the future.
> >     >
> >     > Alternative solutions:
> >     > - It has repeatedly been suggested to place the log files into a
> >     > memory file system but we don't think this is an optimal solution.
> >     > Main memory is often a constrained resource and we don't want log
> >     > files to compete with the JVM for it in such cases.
> >     > - It has also been argued to place the log files on a fast file
> system
> >     > which is only used for logging but in containerized environments
> file
> >     > system are often virtualized and the properties of the underlying
> >     > physical devices are not obvious.
> >     > - The load on the file system might be unpredictable due to other
> >     > applications on the same host.
> >     > - All these workarounds won't work if we eventually implement
> direct
> >     > logging to a network socket as suggested in [8].
> >     >
> >     > Implementation details / POC:
> >     >
> >     > - A recent pull request [2] for JDK-8229517 [3] proposed to use a
> >     > simple deque implementation derived from HotSpot's LinkedListImpl
> >     > class for the intermediate data structure. It synchronizes access
> to
> >     > the queue with a MutexLocker which is internally implemented with
> >     > pthread_lock() and results in an atomic CAS on the fast path. So
> >     > performance-wise the locking itself is not different from the
> >     > flockfile()/funlockfile() functionality currently used by UL but
> >     > adding a log message to the deque should be constant as it
> basically
> >     > only requires a strdup(). And we could even eliminate the strdup()
> if
> >     > we'd pre-allocate a big enough array for holding the log messages
> as
> >     > proposed in the pull request [2].
> >     > - The pull pull request [2] for JDK-8229517 [3] proposed to set the
> >     > async flag as an attribute of the Xlog option which feels more
> natural
> >     > because UL configuration is traditionally done within the Xlog
> option.
> >     > But we could just as well use a global -XX flag to enable async
> >     > logging? What are your preferences here?
> >     > - The pull pull request [2] for JDK-8229517 [3] (mis)uses the
> >     > WatcherThread as service thread to concurrently process the
> >     > intermediate data structure and write the log messages out to the
> log
> >     > stream. That should definitely be changed to an independent service
> >     > thread.
> >     > - The pull pull request [2] for JDK-8229517 [3] initially proposed
> >     > that the "service thread" runs at a fixed interval to dump log
> >     > messages to the log streams. But reviewers commented that this
> should
> >     > better happen either continuously or based on the filling level of
> the
> >     > intermediate data structure. What are your preferences here?
> >     > - What are your preferences on the configuration of the
> intermediate
> >     > data structure? Should it be configured based on the maximum
> number of
> >     > log messages it can store or rather on the total size of the stored
> >     > log messages? I think that for normal runs this distinction
> probably
> >     > won't make a big difference because the size of log messages will
> >     > probably be the same on average so "number of log messages" should
> >     > always be proportional to "total size of log mesages".
> >     >
> >     > 1. Before diving into more implementation details, I'd first like
> to
> >     > reach a general consensus that asynchronous logging is a useful
> >     > feature that's worth while adding to HotSpot.
> >     >
> >     > 2. Once we agree on that, we should agree on the desired
> properties of
> >     > asynchronous logging. I've tried to collect a basic set in the
> >     > "Proposed solution" section.
> >     >
> >     > 3. If that's done as well, we can discuss various implementation
> >     > details and finally prepare new pull requests.
> >     >
> >     > Thank you and best regards,
> >     > Volker
> >     >
> >     > [1] https://bugs.openjdk.java.net/browse/JDK-8229517
> >     <https://bugs.openjdk.java.net/browse/JDK-8229517>
> >     > [2] https://github.com/openjdk/jdk/pull/3135
> >     <https://github.com/openjdk/jdk/pull/3135>
> >     > [3]
> >
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
> >     <
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
> >
> >     > [4]
> >
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
> >     <
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
> >
> >     > [5] https://openjdk.java.net/jeps/158
> >     <https://openjdk.java.net/jeps/158>
> >     > [6] https://openjdk.java.net/jeps/271
> >     <https://openjdk.java.net/jeps/271>
> >     > [7] https://man7.org/linux/man-pages/man3/stdio.3.html
> >     <https://man7.org/linux/man-pages/man3/stdio.3.html>
> >     > [8]
> >     https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d
> >     <https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d>
> >     > [9] https://man7.org/linux/man-pages/man3/flockfile.3.html
> >     <https://man7.org/linux/man-pages/man3/flockfile.3.html>
> >     > [10] https://man7.org/linux/man-pages/man2/futex.2.html
> >     <https://man7.org/linux/man-pages/man2/futex.2.html>
> >     >
> >
>

From iwalulya at openjdk.java.net  Wed May 12 09:11:17 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 12 May 2021 09:11:17 GMT
Subject: Integrated: 8233378: CHT: Fast reset
In-Reply-To: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
References: <Tn9gX6eqMZhqTq30HnO1JcmqBsJbTAgGfDGVFO7i-Js=.d7f97cf0-43f7-4ee3-844b-a634a0121373@github.com>
Message-ID: <L7sB1-0YzKH3kXMnOqWrOjAuRDHnG84sRrR4KBf6Ie4=.a4d14937-4598-4e0a-9661-d8ab959a5b4f@github.com>

On Mon, 10 May 2021 14:08:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to add a dedicated method that just resets the internal table (optionally setting it to a new size) without going through new/delete of the CHT. Currently, the CHT destructor calls Value::destroy_node() on every element in the table which may be very slow for some use-cases.
> 
> Testing: tier 1-3 (Linux, Windows).

This pull request has now been integrated.

Changeset: dcf250d5
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dcf250d5d41a05d0f3213fb9a807e89e1c198ce5
Stats:     101 lines in 3 files changed: 98 ins; 0 del; 3 mod

8233378: CHT: Fast reset

Reviewed-by: tschatzl, rehn

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

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

From sjohanss at openjdk.java.net  Wed May 12 10:07:02 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 12 May 2021 10:07:02 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
Message-ID: <_dLkyN8n_EqunRmqfEjoVoyq2EvGVyQ15fTswnzWbqA=.84f1e995-7242-474d-bff3-675c296cc2bd@github.com>

On Fri, 7 May 2021 16:16:22 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - Remove extranous vm_page_size check
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - kstefanj review
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Set LargePageSizeInBytes to largepage upper limit
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Fix merge
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Merge branch 'master' into update_hlp
>  - Merge branch 'master' into update_hlp
>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4

While doing some manual testing I found a problem when setting `LargePageSizeInBytes=1g`, but without having any 1g pages configured. In that case, we will turn off `UseLargePages` even if there are 2m pages configured. 

Not sure if we should address this as part of this change or as a follow up, but I think the `hugetlbfs_sanity_check(...)` should check that at least one of the supported large pages are configured, not just the one set as the maximum large page size.

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

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

From vlivanov at openjdk.java.net  Wed May 12 10:30:54 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 10:30:54 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v4]
In-Reply-To: <CSHp8znqkPBWv-ZYnzs7F5pwYjeGBvXaIlrAC3sFuRY=.9817e320-9658-492e-829a-eb7063fe774b@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <CSHp8znqkPBWv-ZYnzs7F5pwYjeGBvXaIlrAC3sFuRY=.9817e320-9658-492e-829a-eb7063fe774b@github.com>
Message-ID: <g2XW-09aDW5pYWdChVK7G41h8hsGG_x8SWDo1cef9Mc=.5abe6ca1-2edd-4fc8-bb4b-6c1de7604196@github.com>

On Wed, 12 May 2021 05:31:46 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

The only way to trigger the problem without VM anonymous classes is to load the same class file by numerous class loaders and then construct `MethodHandle`s for some method in that class. It should be affected by the same problem with the hash function which uses only symbolic info. 

But I'm not sure how much numerous class loaders themselves will stretch the JVM. It can easily make the effects of `ResolvedMethodTable` negligible.
 
Nevertheless, IMO it still makes sense to improve the hash function.


unsigned int method_hash(const Method* method) {
  unsigned int hash = method->klass_name()->identity_hash();
  hash = (hash * 31) ^ method->name()->identity_hash();
  hash = (hash * 31) ^ method->signature()->identity_hash();
  return hash;
}


There's the method address available (`Method*`) which can easily be mixed (as an additional component or as a replacement for any of existing components: method name/signature/holder holder name.

For example, here's how `Symbol::identity_hash()` looks loke: 


class Symbol : public MetaspaceObj {
...
  unsigned identity_hash() const {
    unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
    return ((unsigned)extract_hash(_hash_and_refcount) & 0xffff) |
           ((addr_bits ^ (length() << 8) ^ (( _body[0] << 8) | _body[1])) << 16);
  }

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

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

From ddong at openjdk.java.net  Wed May 12 11:14:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 12 May 2021 11:14:25 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v5]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <XuPl4LgblTqj2oraVCp4rKFwi5jq-SxBaRub7F0dtEo=.9686301a-8fad-471e-80e0-bc90051ebd26@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

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

  update the implementation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/6a089b24..b20036a3

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

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

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

From ddong at openjdk.java.net  Wed May 12 11:14:26 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 12 May 2021 11:14:26 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v4]
In-Reply-To: <g2XW-09aDW5pYWdChVK7G41h8hsGG_x8SWDo1cef9Mc=.5abe6ca1-2edd-4fc8-bb4b-6c1de7604196@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <CSHp8znqkPBWv-ZYnzs7F5pwYjeGBvXaIlrAC3sFuRY=.9817e320-9658-492e-829a-eb7063fe774b@github.com>
 <g2XW-09aDW5pYWdChVK7G41h8hsGG_x8SWDo1cef9Mc=.5abe6ca1-2edd-4fc8-bb4b-6c1de7604196@github.com>
Message-ID: <1U6lIvNE5pnyct-BA9CGwLjg5lYop5K1Y_IolYIyb-c=.687640c1-d523-4890-a189-33bbb2f76c66@github.com>

On Wed, 12 May 2021 10:27:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The only way to trigger the problem without VM anonymous classes is to load the same class file by numerous class loaders and then construct `MethodHandle`s for some method in that class. It should be affected by the same problem with the hash function which uses only symbolic info.
> 
> But I'm not sure how much numerous class loaders themselves will stretch the JVM. It can easily make the effects of `ResolvedMethodTable` negligible.
> 
> Nevertheless, IMO it still makes sense to improve the hash function.
> 
> ```
> unsigned int method_hash(const Method* method) {
>   unsigned int hash = method->klass_name()->identity_hash();
>   hash = (hash * 31) ^ method->name()->identity_hash();
>   hash = (hash * 31) ^ method->signature()->identity_hash();
>   return hash;
> }
> ```
> 
> There's the method address available (`Method*`) which can easily be mixed (as an additional component or as a replacement for any of existing components: method name/signature/holder holder name.
> 
> For example, here's how `Symbol::identity_hash()` looks loke:
> 
> ```
> class Symbol : public MetaspaceObj {
> ...
>   unsigned identity_hash() const {
>     unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
>     return ((unsigned)extract_hash(_hash_and_refcount) & 0xffff) |
>            ((addr_bits ^ (length() << 8) ^ (( _body[0] << 8) | _body[1])) << 16);
>   }
> ```

Hi Vladimir,

Thanks for the comment.
I have updated the implementation according to your suggestion.

Thanks,
Denghui

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

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

From tschatzl at openjdk.java.net  Wed May 12 11:36:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 12 May 2021 11:36:08 GMT
Subject: RFR: 8266904: Use function pointer typedefs in
 OopOopIterateDispatch
In-Reply-To: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
References: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
Message-ID: <HQxHVaj5KhVqOkRasHtJUdOs8uOWEvpt_ARwGy2lbhQ=.e0772c65-fc44-4794-bf51-17c293b5313f@github.com>

On Tue, 11 May 2021 19:44:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The way our OopIterateClosures are devirtualized is quite complex. I think we can lower the complexity a tiny bit by using a function pointer typedef.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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

From vlivanov at openjdk.java.net  Wed May 12 14:08:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:08:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
Message-ID: <FpIQHDTsWfnxK3nxv8jAhS6l7kf4LraPAfXHUKeDK8A=.ec55a482-fb40-4abf-9a9b-3d92e0faa3b1@github.com>

On Mon, 10 May 2021 20:43:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

Overall, hotspot and java.lang.invoke changes look good.

One comment though on naming: there are multiple references to Panama in the code. Moreover, it is used inconsistently (`is_panama_entry_frame()` vs `EntryBlob` vs `OptimizedUpcallStub`). 
I suggest to get rid of any references to Panama and use `optimized`uniformly where appropriate (`is_optimized_entry_frame()`, `OptimizedEntryBlob`, `OptimizedUpcallStub`).

Some minor comments follow.

src/hotspot/share/prims/universalUpcallHandler.cpp line 122:

> 120: JNI_END
> 121: 
> 122: JVM_ENTRY(jlong, PUH_AllocateOptimzedUpcallStub(JNIEnv *env, jclass unused, jobject mh, jobject abi, jobject conv))

Typo: `PUH_AllocateOptimzedUpcallStub` -> `PUH_AllocateOptimizedUpcallStub`.

src/hotspot/share/prims/universalUpcallHandler.cpp line 137:

> 135: JVM_END
> 136: 
> 137: JVM_ENTRY(jboolean, PUH_SupportsOptimzedUpcalls(JNIEnv *env, jclass unused))

Typo: `Optimzed` -> `Optimized`

src/hotspot/share/runtime/sharedRuntime.hpp line 465:

> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
> 464: 
> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);

Please, file an RFE to move these declarations to `MacroAssembler`.

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

Marked as reviewed by vlivanov (Reviewer).

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

From iwalulya at openjdk.java.net  Wed May 12 14:22:14 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 12 May 2021 14:22:14 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v2]
In-Reply-To: <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
 <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
Message-ID: <iWtrpMVXx5EbGARcyji2WH4c_-YixyUg-t8c9EaVoC4=.56b59950-1f47-43d3-a56f-3dd9f01bd270@github.com>

On Wed, 12 May 2021 07:45:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
>> 
>> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
>> 
>> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
>> 
>> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
>> 
>> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
>> 
>> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

lgtm!

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

Marked as reviewed by iwalulya (Committer).

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

From vlivanov at openjdk.java.net  Wed May 12 14:38:18 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:38:18 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
Message-ID: <C5p_aLVHjo6sHpLD1s8j17tFPpYSJqZwvjB3fPAifdY=.f71211b1-d6fa-4410-ba3b-77c96b98be44@github.com>

On Mon, 10 May 2021 20:43:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:

> 470:   __ block_comment("} preserve_callee_saved_regs ");
> 471: 
> 472:   // TODO mxcsr

Anything left to do with mxcsr?

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

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

From jvernee at openjdk.java.net  Wed May 12 14:58:56 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 12 May 2021 14:58:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <C5p_aLVHjo6sHpLD1s8j17tFPpYSJqZwvjB3fPAifdY=.f71211b1-d6fa-4410-ba3b-77c96b98be44@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
 <C5p_aLVHjo6sHpLD1s8j17tFPpYSJqZwvjB3fPAifdY=.f71211b1-d6fa-4410-ba3b-77c96b98be44@github.com>
Message-ID: <PSmocMgV3zR9cXP66XUVZyJtpbutDa7EskW-CsU64yA=.df3e4540-8cc3-43ca-93e2-8ff6cdf0af3a@github.com>

On Wed, 12 May 2021 14:06:46 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
> 
>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>> 471: 
>> 472:   // TODO mxcsr
> 
> Anything left to do with mxcsr?

I guess this slipped through with the initial PR.

JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298

However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr

I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

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

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

From mcimadamore at openjdk.java.net  Wed May 12 15:11:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 12 May 2021 15:11:51 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <FpIQHDTsWfnxK3nxv8jAhS6l7kf4LraPAfXHUKeDK8A=.ec55a482-fb40-4abf-9a9b-3d92e0faa3b1@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
 <FpIQHDTsWfnxK3nxv8jAhS6l7kf4LraPAfXHUKeDK8A=.ec55a482-fb40-4abf-9a9b-3d92e0faa3b1@github.com>
Message-ID: <UKuyvOUrzbCSZWT3GAYNUCW6sFRjXthhxYpwuWL1oXQ=.fa4d1084-3e17-495e-8165-4b9e9ab18236@github.com>

On Wed, 12 May 2021 13:57:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
> 
>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>> 464: 
>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
> 
> Please, file an RFE to move these declarations to `MacroAssembler`.

There's already an issue for that:
https://bugs.openjdk.java.net/browse/JDK-8266257

I've upgraded the description to make it reflect the proposed move a bit more precisely.

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

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

From tschatzl at openjdk.java.net  Wed May 12 15:22:58 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 12 May 2021 15:22:58 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>
Message-ID: <mp1Q34J8I2byMdwna1bqZL3tkCm9ImM11vZJpaLxOz0=.38771ca1-a78e-4658-9dbb-833fa5eea8be@github.com>

On Fri, 7 May 2021 08:28:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments

Lgtm.

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 82:

> 80: // Doing so would counteract C2 optimizations on string literals.  But an
> 81: // interned string might later become a deduplication candidate through the
> 82: // normal GC discovery mechanism.  To prevent such modificatoins, the

s/modificatoins/modifications

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

Marked as reviewed by tschatzl (Reviewer).

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

From mgkwill at openjdk.java.net  Wed May 12 15:47:30 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 15:47:30 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v33]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <Sy8cR2WBdYSI2gkuuG6mnBzeXTQdcCIJZUyOsc9qjIY=.3adc21b0-29f5-41b7-8b5f-f44015f7760b@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Review comments 5_12
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1153/files
  - new: https://git.openjdk.java.net/jdk/pull/1153/files/7368e7d4..024cbc50

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=32
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=31-32

  Stats: 33 lines in 1 file changed: 17 ins; 7 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153

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

From mgkwill at openjdk.java.net  Wed May 12 15:47:39 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 15:47:39 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v32]
In-Reply-To: <hTO2yIX9M67DHSDQAjlh89TfSF_DHTRBtTs93-v4Pj4=.c53c09e3-4093-4a8a-9648-44e7acae4055@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <aIzJvKW8SBBSW0il3ZUxJPSi5hWoRLQ6lsG21OQVXWk=.b6f42040-1f1a-4411-8496-a3c630041b5a@github.com>
 <hTO2yIX9M67DHSDQAjlh89TfSF_DHTRBtTs93-v4Pj4=.c53c09e3-4093-4a8a-9648-44e7acae4055@github.com>
Message-ID: <7wSzAA1-XA1xCxWYIPwOGNHqaHZqbrzZsF6O4fhwmH0=.af7b24d0-5871-452c-aa5f-424aa6affcd0@github.com>

On Tue, 11 May 2021 10:19:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
>> 
>>  - Remove reserve_memory_special_huge_tlbfs mods except assert
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Merge branch 'master' into update_hlp
>>  - Remove extranous vm_page_size check
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - kstefanj review
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Set LargePageSizeInBytes to largepage upper limit
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Fix merge
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Merge branch 'master' into update_hlp
>>  - Merge branch 'master' into update_hlp
>>  - ... and 43 more: https://git.openjdk.java.net/jdk/compare/0790e601...7368e7d4
>
> src/hotspot/os/linux/os_linux.cpp line 3765:
> 
>> 3763:     LogStream ls(lt);
>> 3764:     ls.print("Available page sizes: ");
>> 3765:     _page_sizes.print_on(&ls);
> 
> I'd prefer to log *all* page sizes, not the filtered list we use. Or print both, "All" and "Usable"?

Agreed.

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

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

From hseigel at openjdk.java.net  Wed May 12 16:10:25 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:25 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <CaV6MEL82hBZVDl3y7mx3R7jTViXiOwZbNANa6_MK0Y=.91800e73-844d-4d5a-819e-b125cd77ebda@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

Thanks Alan, Ioi, and Mandy for looking at this.  The latest changes should address the issues that you found.
Harold

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

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

From hseigel at openjdk.java.net  Wed May 12 16:10:24 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:24 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  test changes and small fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/874a1603..5246dd76

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

  Stats: 286 lines in 10 files changed: 22 ins; 256 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

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

From hseigel at openjdk.java.net  Wed May 12 16:10:26 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:26 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <sJyvFHU5KhmFEbzS8UO7tPFY0Koxct_h6PUKvx38hqg=.0de94f46-7bf2-4500-8a26-30fdc83a8cc8@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
 <sJyvFHU5KhmFEbzS8UO7tPFY0Koxct_h6PUKvx38hqg=.0de94f46-7bf2-4500-8a26-30fdc83a8cc8@github.com>
Message-ID: <6vXfHjNzHSk46muMlntg2ZqE1OSmHx0eg08V-3AqIvc=.2dbd90d5-453a-4447-abfd-9aebfff9143d@github.com>

On Tue, 11 May 2021 17:07:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix GetModuleTest.java
>
> src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65:
> 
>> 63:         // so when handling the java mirror for the class we need to make sure its class
>> 64:         // loader data is claimed, this is done by calling do_cld explicitly.
>> 65:         // For non-string hidden classes the call to do_cld is made when the class
> 
> Typo: non-strong

fixed, thanks for finding this.

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

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

From hseigel at openjdk.java.net  Wed May 12 16:10:27 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:27 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
 <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>
Message-ID: <ltY7CzN_ay0uBhRGthL1ZavkQkycONKJ4LbzYas7T5I=.8a4fbbf2-8b7b-40f8-a19c-b4856c3c5e63@github.com>

On Tue, 11 May 2021 20:49:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix GetModuleTest.java
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53:
> 
>> 51:             return simpleName;
>> 52:         }
>> 53:         // Must be a local class
> 
> This file should not be changed.  It refers to the Java language anonymous class (not VM anonymous class).

Changes have been restored.

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

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

From mgkwill at openjdk.java.net  Wed May 12 16:16:33 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 16:16:33 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v34]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <MRbMILkFGvIK1yozvcqPjCzvqxWXh3fb3j-JKq-bHpI=.73621968-3cdc-4844-8414-0d58b5a97a53@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Check large pages =< _large_page_size
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1153/files
  - new: https://git.openjdk.java.net/jdk/pull/1153/files/024cbc50..7a3c1e42

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=33
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=32-33

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

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

From coleenp at openjdk.java.net  Wed May 12 16:22:21 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 12 May 2021 16:22:21 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v5]
In-Reply-To: <XuPl4LgblTqj2oraVCp4rKFwi5jq-SxBaRub7F0dtEo=.9686301a-8fad-471e-80e0-bc90051ebd26@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <XuPl4LgblTqj2oraVCp4rKFwi5jq-SxBaRub7F0dtEo=.9686301a-8fad-471e-80e0-bc90051ebd26@github.com>
Message-ID: <PfyyxhgrzJPXExit_jweyvptoI4AmJ5cZA7v8Yz1PTE=.b83f1b2f-5cfa-46a1-803f-7a44a2529447@github.com>

On Wed, 12 May 2021 11:14:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the implementation

src/hotspot/share/prims/resolvedMethodTable.cpp line 59:

> 57:   hash = (hash * 31) ^ method->name()->identity_hash();
> 58:   hash = (hash * 31) ^ method->signature()->identity_hash();
> 59:   return hash ^ (unsigned)((uintptr_t)method >> (LogMinObjAlignmentInBytes + 3));

I agree with Vladimir that it makes sense to improve the hashing function of the ResolvedMethodTable for the special case of names matching.  You have to use the ClassLoaderData though, not the Method* because the reason for the table is to replace Method* in the case of redefinition.

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

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

From chris at sageembedded.com  Wed May 12 17:02:32 2021
From: chris at sageembedded.com (Chris Cole)
Date: Wed, 12 May 2021 10:02:32 -0700
Subject: Bug in monitor locking/unlocking on ARM32 C1 due to uninitialized
 BasicObjectLock::_displaced_header
Message-ID: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>

Hi,

Not sure if this is the appropriate place or method to report an OpenJDK
bug, if not please advise.

I have discovered a bug with ARM32 C1 monitor locking/unlocking that can
result in deadlock. The bug was introduced with JCK-8241234 "Unify monitor
enter/exit runtime entries" [1]. This change introduced a call to
ObjectSynchronizer::quick_entry() within the logic for
Runtime1::monitorenter().
If the monitor is inflated and already owned by the current thread, then
ObjectSynchronizer::quick_entry() simply increments
ObjectMonitor::_recursions and returns. In this case
Runtime1::monitorenter() returns to the JIT compiled code without calling
"lock->set_displaced_header(markWord::unused_mark())" (see [2]). For ARM32
the _displaced_header field is not always initialized in JIT code before
calling Runtime1::monitorenter() helper. If the uninitialized value of
_displaced_header field on stack happens to be NULL, this causes an issue
because the JIT code to exit the monitor first checks for a NULL
_displaced_header as an indication for non-inflated recursive locking which
is a noop for exiting the monitor (see [3]). This means that the
Runtime1::monitorexit() helper is not called as required to exit this
inflated monitor, and the ObjectMonitor::_recursions is not decremented as
required. This leads to thread not unlocking the monitor when required and
deadlock when another thread tries to lock the monitor.

This bug is not present on AArch64 and x86, because the displaced header is
initialized in JIT code with the "unlocked object header" value (which is
non-zero) before calling Runtime1::monitorenter() helper (see [4] and [5]).
Note sure about other CPU architectures.

I see two ways to fix this.
1) In ObjectSynchronizer::quick_entry() move the
"lock->set_displaced_header(markWord::unused_mark())" statement to before
the "if (owner == current)" at line 340 in share/runtime/synchronizer.cpp
(see [6]), so that Runtime1::monitorenter() helper logic always initializes
the displaced header field as was the case before JCK-8241234.
2) For ARM32 add JIT code to initialize the displaced header field before
calling Runtime1::monitorenter() helper as done for AArch64 and x86.

Not sure which is better (or maybe both are required for some reason I am
not aware of). I believe this "displacted header" on the stack can be
looked at by stack walkers but I am not familiar with the exact details and
if there are implications on this fix.

The bug is also present in OpenJDK 11.0.10 and later (introduced by the
backport of JDK-8241234 [1]).

I/my company (Sage Embedded Software) has signed the Oracle Contributor
Agreement (OCA) and have been granted access to JCK.

The bug can be reproduced in my environment with the OpenJDK Community TCK
testing of java.io.PipedReader that deadlocks, but because reproduction of
the issue requires uninitialized stack field to be zero, it might not
happen in some environments. I have a Java test case that can reproduce
this issue on ARM in 32 bit mode. It is pasted inline below at the end of
the email. There is a "getZeroOnStack()" method that I think helps get a
zero into the uninitialized _displaced_header field. The test case source
code is copied from OpenJDK java.io.PipedReader source code and then
modified. It needs to be run with only C1 enabled (I am using minimal
variant to enforce this) and the following command line options
(-XX:-BackgroundCompilation -XX:CompileThreshold=500
-XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"). The test
case should run and then end with "Source thread done" and "Reading
complete" output if the bug is not reproduced. If the monitor bug is
reproduced the test case will not exit and the main thread will be
deadlocked, with the main thread last printing "read() before wait" and
missing "read() after wait" and "Reading complete". If useful I can provide
the output of this test cause including -XX:PrintAssebly and logging that I
added to ObjectSynchronizer::quick_entry() that shows uninitialized
lock->_displaced_header and ObjectMonitor->_recursions continue to get
incremented (into the 1000s) as the MonitorBugTest.receive() method is
called in a loop.

Please let me know if there is anything else that would be helpful. I hope
to become active in the OpenJDK Community. My time is a little limited at
the moment, so sometimes it might take a day to respond (I have 3 and 6
year old kids). In the coming years I expect to have additional time to be
more involved in the OpenJDK Community.

Best regards,
Chris Cole
Sage Embedded Software LLC

[1] https://bugs.openjdk.java.net/browse/JDK-8241234
[2]
https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L343
[3]
https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L130
[4]
https://github.com/openjdk/jdk/blob/71b8ad45b4de6836e3bb2716ebf136f3f8ea2198/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp#L95
[5]
https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74
[6]
https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L340

/*
 * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights
reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

package com.sageembedded.test;

import java.io.IOException;
import java.io.InterruptedIOException;

/*
 * java -cp bin -minimal -XX:-BackgroundCompilation -XX:CompileThreshold=500
 *  -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"
 *  -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
 *  com.sageembedded.test.MonitorBugTest
 */
public class MonitorBugTest {

        private static int DATA_SIZE = 1000;
        private static int BUFFER_SIZE = 256;

        private char buffer[] = new char[BUFFER_SIZE];
        private int writeIndex = -1;
        private int readIndex = 0;

        public Object lock = new Object();

        public static void main(String[] args) {
                MonitorBugTest test = new MonitorBugTest();
                test.run();
        }
        private void run() {
                System.out.println("Starting test");

                SourceThread source = new SourceThread();
                source.start();

                try {
                        for (int i = 0; i < DATA_SIZE; i++) {
                                read();
                        }
                } catch (IOException e) {
                        e.printStackTrace();
                }
                System.out.println("Reading complete");

        }

        synchronized void receive(char data[], int offset, int length)
throws IOException {
                while (--length >= 0) {
                        getZeroOnStack(offset);
                        receive(data[offset++]);
                }
        }

        private void getZeroOnStack(int offset) {
                int l1;
                int l2;
                int l3;
                int l4;
                int l5;
                int l6;
                int l7;
                int l8;
                int l9;
                int l10;
                int l11;
                int l12;
                int l13;
                int l14;
                int l15;
                int l16;

                l1 = 0;
                l2 = 0;
                l3 = 0;
                l4 = 0;
                l5 = 0;
                l6 = 0;
                l7 = 0;
                l8 = 0;
                l9 = 0;
                l10 = 0;
                l11 = 0;
                l12 = 0;
                l13 = 0;
                l14 = 0;
                l15 = 0;
                l16 = 0;
        }

        synchronized void receive(int c) throws IOException {
                while (writeIndex == readIndex) {
                        notifyAll();
                        try {
                                wait(1000);
                        } catch (InterruptedException e) {
                                throw new InterruptedIOException();
                        }
                }
                if (writeIndex < 0) {
                        writeIndex = 0;
                        readIndex = 0;
                }
                buffer[writeIndex++] = (char) c;
                if (writeIndex >= buffer.length) {
                        writeIndex = 0;
                }
        }

        synchronized void last() {
                notifyAll();
        }
        public synchronized int read() throws IOException {
                while (writeIndex < 0) {
                        notifyAll();
                        try {
                                System.out.println("read() before wait");
                                wait(1000);
                                System.out.println("read() after wait");
                        } catch (InterruptedException e) {
                                throw new InterruptedIOException();
                        }
                }
                int value = buffer[readIndex++];
                if (readIndex >= buffer.length) {
                        readIndex = 0;
                }
                if (writeIndex == readIndex) {
                        writeIndex = -1;
                }
                return value;
        }

        private class SourceThread extends Thread {
                @Override
                public void run() {
                        System.out.println("Source thread start");
                        char data[] = new char[DATA_SIZE];
                        try {
                                receive(data, 0, data.length);
                                last();
                        } catch (IOException e) {
                                e.printStackTrace();
                        }
                        System.out.println("Source thread done");
                }
        }
}

From daniel.daugherty at oracle.com  Wed May 12 17:21:32 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Wed, 12 May 2021 13:21:32 -0400
Subject: Bug in monitor locking/unlocking on ARM32 C1 due to uninitialized
 BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
Message-ID: <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>

Hi Chris,

I filed the following new bug on your behalf:

JDK-8267042 bug in monitor locking/unlocking on ARM32 C1 due to 
uninitialized BasicObjectLock::_displaced_header
https://bugs.openjdk.java.net/browse/JDK-8267042

Dan


On 5/12/21 1:02 PM, Chris Cole wrote:
> Hi,
>
> Not sure if this is the appropriate place or method to report an OpenJDK
> bug, if not please advise.
>
> I have discovered a bug with ARM32 C1 monitor locking/unlocking that can
> result in deadlock. The bug was introduced with JCK-8241234 "Unify monitor
> enter/exit runtime entries" [1]. This change introduced a call to
> ObjectSynchronizer::quick_entry() within the logic for
> Runtime1::monitorenter().
> If the monitor is inflated and already owned by the current thread, then
> ObjectSynchronizer::quick_entry() simply increments
> ObjectMonitor::_recursions and returns. In this case
> Runtime1::monitorenter() returns to the JIT compiled code without calling
> "lock->set_displaced_header(markWord::unused_mark())" (see [2]). For ARM32
> the _displaced_header field is not always initialized in JIT code before
> calling Runtime1::monitorenter() helper. If the uninitialized value of
> _displaced_header field on stack happens to be NULL, this causes an issue
> because the JIT code to exit the monitor first checks for a NULL
> _displaced_header as an indication for non-inflated recursive locking which
> is a noop for exiting the monitor (see [3]). This means that the
> Runtime1::monitorexit() helper is not called as required to exit this
> inflated monitor, and the ObjectMonitor::_recursions is not decremented as
> required. This leads to thread not unlocking the monitor when required and
> deadlock when another thread tries to lock the monitor.
>
> This bug is not present on AArch64 and x86, because the displaced header is
> initialized in JIT code with the "unlocked object header" value (which is
> non-zero) before calling Runtime1::monitorenter() helper (see [4] and [5]).
> Note sure about other CPU architectures.
>
> I see two ways to fix this.
> 1) In ObjectSynchronizer::quick_entry() move the
> "lock->set_displaced_header(markWord::unused_mark())" statement to before
> the "if (owner == current)" at line 340 in share/runtime/synchronizer.cpp
> (see [6]), so that Runtime1::monitorenter() helper logic always initializes
> the displaced header field as was the case before JCK-8241234.
> 2) For ARM32 add JIT code to initialize the displaced header field before
> calling Runtime1::monitorenter() helper as done for AArch64 and x86.
>
> Not sure which is better (or maybe both are required for some reason I am
> not aware of). I believe this "displacted header" on the stack can be
> looked at by stack walkers but I am not familiar with the exact details and
> if there are implications on this fix.
>
> The bug is also present in OpenJDK 11.0.10 and later (introduced by the
> backport of JDK-8241234 [1]).
>
> I/my company (Sage Embedded Software) has signed the Oracle Contributor
> Agreement (OCA) and have been granted access to JCK.
>
> The bug can be reproduced in my environment with the OpenJDK Community TCK
> testing of java.io.PipedReader that deadlocks, but because reproduction of
> the issue requires uninitialized stack field to be zero, it might not
> happen in some environments. I have a Java test case that can reproduce
> this issue on ARM in 32 bit mode. It is pasted inline below at the end of
> the email. There is a "getZeroOnStack()" method that I think helps get a
> zero into the uninitialized _displaced_header field. The test case source
> code is copied from OpenJDK java.io.PipedReader source code and then
> modified. It needs to be run with only C1 enabled (I am using minimal
> variant to enforce this) and the following command line options
> (-XX:-BackgroundCompilation -XX:CompileThreshold=500
> -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"). The test
> case should run and then end with "Source thread done" and "Reading
> complete" output if the bug is not reproduced. If the monitor bug is
> reproduced the test case will not exit and the main thread will be
> deadlocked, with the main thread last printing "read() before wait" and
> missing "read() after wait" and "Reading complete". If useful I can provide
> the output of this test cause including -XX:PrintAssebly and logging that I
> added to ObjectSynchronizer::quick_entry() that shows uninitialized
> lock->_displaced_header and ObjectMonitor->_recursions continue to get
> incremented (into the 1000s) as the MonitorBugTest.receive() method is
> called in a loop.
>
> Please let me know if there is anything else that would be helpful. I hope
> to become active in the OpenJDK Community. My time is a little limited at
> the moment, so sometimes it might take a day to respond (I have 3 and 6
> year old kids). In the coming years I expect to have additional time to be
> more involved in the OpenJDK Community.
>
> Best regards,
> Chris Cole
> Sage Embedded Software LLC
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8241234
> [2]
> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L343
> [3]
> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L130
> [4]
> https://github.com/openjdk/jdk/blob/71b8ad45b4de6836e3bb2716ebf136f3f8ea2198/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp#L95
> [5]
> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74
> [6]
> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L340
>
> /*
>   * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License version 2 only, as
>   * published by the Free Software Foundation.  Oracle designates this
>   * particular file as subject to the "Classpath" exception as provided
>   * by Oracle in the LICENSE file that accompanied this code.
>   *
>   * This code is distributed in the hope that it will be useful, but WITHOUT
>   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>   * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>   * version 2 for more details (a copy is included in the LICENSE file that
>   * accompanied this code).
>   *
>   * You should have received a copy of the GNU General Public License version
>   * 2 along with this work; if not, write to the Free Software Foundation,
>   * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>   *
>   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>   * or visit www.oracle.com if you need additional information or have any
>   * questions.
>   */
>
> package com.sageembedded.test;
>
> import java.io.IOException;
> import java.io.InterruptedIOException;
>
> /*
>   * java -cp bin -minimal -XX:-BackgroundCompilation -XX:CompileThreshold=500
>   *  -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"
>   *  -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
>   *  com.sageembedded.test.MonitorBugTest
>   */
> public class MonitorBugTest {
>
>          private static int DATA_SIZE = 1000;
>          private static int BUFFER_SIZE = 256;
>
>          private char buffer[] = new char[BUFFER_SIZE];
>          private int writeIndex = -1;
>          private int readIndex = 0;
>
>          public Object lock = new Object();
>
>          public static void main(String[] args) {
>                  MonitorBugTest test = new MonitorBugTest();
>                  test.run();
>          }
>          private void run() {
>                  System.out.println("Starting test");
>
>                  SourceThread source = new SourceThread();
>                  source.start();
>
>                  try {
>                          for (int i = 0; i < DATA_SIZE; i++) {
>                                  read();
>                          }
>                  } catch (IOException e) {
>                          e.printStackTrace();
>                  }
>                  System.out.println("Reading complete");
>
>          }
>
>          synchronized void receive(char data[], int offset, int length)
> throws IOException {
>                  while (--length >= 0) {
>                          getZeroOnStack(offset);
>                          receive(data[offset++]);
>                  }
>          }
>
>          private void getZeroOnStack(int offset) {
>                  int l1;
>                  int l2;
>                  int l3;
>                  int l4;
>                  int l5;
>                  int l6;
>                  int l7;
>                  int l8;
>                  int l9;
>                  int l10;
>                  int l11;
>                  int l12;
>                  int l13;
>                  int l14;
>                  int l15;
>                  int l16;
>
>                  l1 = 0;
>                  l2 = 0;
>                  l3 = 0;
>                  l4 = 0;
>                  l5 = 0;
>                  l6 = 0;
>                  l7 = 0;
>                  l8 = 0;
>                  l9 = 0;
>                  l10 = 0;
>                  l11 = 0;
>                  l12 = 0;
>                  l13 = 0;
>                  l14 = 0;
>                  l15 = 0;
>                  l16 = 0;
>          }
>
>          synchronized void receive(int c) throws IOException {
>                  while (writeIndex == readIndex) {
>                          notifyAll();
>                          try {
>                                  wait(1000);
>                          } catch (InterruptedException e) {
>                                  throw new InterruptedIOException();
>                          }
>                  }
>                  if (writeIndex < 0) {
>                          writeIndex = 0;
>                          readIndex = 0;
>                  }
>                  buffer[writeIndex++] = (char) c;
>                  if (writeIndex >= buffer.length) {
>                          writeIndex = 0;
>                  }
>          }
>
>          synchronized void last() {
>                  notifyAll();
>          }
>          public synchronized int read() throws IOException {
>                  while (writeIndex < 0) {
>                          notifyAll();
>                          try {
>                                  System.out.println("read() before wait");
>                                  wait(1000);
>                                  System.out.println("read() after wait");
>                          } catch (InterruptedException e) {
>                                  throw new InterruptedIOException();
>                          }
>                  }
>                  int value = buffer[readIndex++];
>                  if (readIndex >= buffer.length) {
>                          readIndex = 0;
>                  }
>                  if (writeIndex == readIndex) {
>                          writeIndex = -1;
>                  }
>                  return value;
>          }
>
>          private class SourceThread extends Thread {
>                  @Override
>                  public void run() {
>                          System.out.println("Source thread start");
>                          char data[] = new char[DATA_SIZE];
>                          try {
>                                  receive(data, 0, data.length);
>                                  last();
>                          } catch (IOException e) {
>                                  e.printStackTrace();
>                          }
>                          System.out.println("Source thread done");
>                  }
>          }
> }


From ddong at openjdk.java.net  Wed May 12 17:34:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 12 May 2021 17:34:25 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <tbR6Z_dXTI5hlomfWcHh_Okm1jlTWrDzTYDTFvNADL8=.5313faa4-4433-431d-b51a-4f4a618a1b55@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

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

  use ClassLoaderData* as factor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/b20036a3..c7c54ae2

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

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

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

From ddong at openjdk.java.net  Wed May 12 17:34:26 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 12 May 2021 17:34:26 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v5]
In-Reply-To: <PfyyxhgrzJPXExit_jweyvptoI4AmJ5cZA7v8Yz1PTE=.b83f1b2f-5cfa-46a1-803f-7a44a2529447@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <XuPl4LgblTqj2oraVCp4rKFwi5jq-SxBaRub7F0dtEo=.9686301a-8fad-471e-80e0-bc90051ebd26@github.com>
 <PfyyxhgrzJPXExit_jweyvptoI4AmJ5cZA7v8Yz1PTE=.b83f1b2f-5cfa-46a1-803f-7a44a2529447@github.com>
Message-ID: <7HB3pamSSYkub-EbBwgpkP_WWO_yn1HggGT8KkGhIbc=.3f2288e7-fa0a-4fc9-83c9-a6155c5603ee@github.com>

On Wed, 12 May 2021 16:19:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the implementation
>
> src/hotspot/share/prims/resolvedMethodTable.cpp line 59:
> 
>> 57:   hash = (hash * 31) ^ method->name()->identity_hash();
>> 58:   hash = (hash * 31) ^ method->signature()->identity_hash();
>> 59:   return hash ^ (unsigned)((uintptr_t)method >> (LogMinObjAlignmentInBytes + 3));
> 
> I agree with Vladimir that it makes sense to improve the hashing function of the ResolvedMethodTable for the special case of names matching.  You have to use the ClassLoaderData though, not the Method* because the reason for the table is to replace Method* in the case of redefinition.

fixed, thanks.

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

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

From kbarrett at openjdk.java.net  Wed May 12 18:47:24 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 12 May 2021 18:47:24 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v2]
In-Reply-To: <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
 <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
Message-ID: <DGllZS5-I6bvIYOri_E1V5Ge1TT4JlJ1DLgoAdkm_wM=.175ffb3f-2786-4c3c-b770-cafa5c0774f4@github.com>

On Wed, 12 May 2021 07:45:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
>> 
>> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
>> 
>> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
>> 
>> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
>> 
>> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
>> 
>> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

One minor nit, otherwise looks good.

src/hotspot/share/gc/g1/g1RemSet.cpp line 1085:

> 1083:   G1CardTable::CardValue _dummy_card;
> 1084: 
> 1085:   ~G1MergeHeapRootsPrefetchCache() { }

Better would be a defaulted definition, i.e. `~G1MergeHeapRootsPrefetchCache() = default;`

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

Marked as reviewed by kbarrett (Reviewer).

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

From xliu at openjdk.java.net  Wed May 12 19:20:15 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 12 May 2021 19:20:15 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

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

  Fix build on Windows.
  
  It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/908d2a36..7df8b1ed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=12-13

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

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

From hohensee at amazon.com  Wed May 12 19:39:22 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 12 May 2021 19:39:22 +0000
Subject: Request For Comment: Asynchronous Logging
Message-ID: <1755C5F8-8681-4A3F-94E8-89CA4E458166@amazon.com>

Hi, Thomas,

The submitter (Xin) can finalize once the CSR has been reviewed by, e.g., you. :)

Thanks,
Paul

?-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> on behalf of Thomas St?fe <thomas.stuefe at gmail.com>
Date: Wednesday, May 12, 2021 at 1:31 AM
To: "Liu, Xin" <xxinliu at amazon.com>
Cc: Volker Simonis <volker.simonis at gmail.com>, HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>, David Holmes <David.Holmes at oracle.com>, Robbin Ehn <robbin.ehn at oracle.com>, Yasumasa Suenaga <suenaga at oss.nttdata.com>
Subject: RE: Request For Comment: Asynchronous Logging

>
>
>
I can't. I believe finalization can only be done by Joe Darcy? Not
sure. @David?

..Thomas

On Wed, May 12, 2021 at 9:55 AM Liu, Xin <xxinliu at amazon.com> wrote:

> hi, Thomas,
>
> Thank you for your reasoning. Your arguments are convincing.
>
> I have updated the CSR description.  No matter what, dropping the
> incoming message is trivial. let's keep thing simple.
>
> Can we finalize the CSR?
>
thanks,
> --lx
>
>
>
> On 5/11/21 3:08 AM, Thomas St?fe wrote:
> > *CAUTION*: This email originated from outside of the organization. Do
> > not click links or open attachments unless you can confirm the sender
> > and know the content is safe.
> >
> >
> > Hi Xin, see my answer in the CSR.
> >
> > Cheers, Thomas
> >
> > On Tue, May 11, 2021 at 9:53 AM Liu, Xin <xxinliu at amazon.com
> > <mailto:xxinliu at amazon.com>> wrote:
> >
> >     Hi,
> >
> >     This RFC covers almost all aspects of async logging. Since then, we
> have
> >     drawn many consensus and implemented them one by one.
> >
> >     I still have one open question. What's the discard policy?
> >
> >     Problem statement:
> >     For async-logging, we proposed a lossy non-blocking design. that is
> to
> >     say, the buffer is bounded and we have to drop messages for
> >     non-blocking. The rationale was described: here:
> >     https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487
> >     <https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487>
> >
> >     The discard policy defines which message is dropped at logsite when
> the
> >     buffer is full. There're at least 3 choices.
> >     1. drop the oldest message and proceed to enqueue.
> >     2. give up enqueue attempt. that is to say, the newest message is
> >     discarded.
> >     3. support them both, let user to choose.
> >
> >     It seems different data structures of buffer bias to different
> discard
> >     policy. eg. printk of Linux kernel uses a fixed ringbuffer. It
> chooses
> >     1) because that is naturally done by ringbuffer overwrite.
> >
> >     Folly logging library also supports async writing. They chose 2)
> because
> >     it's straight-forward for a bounded array.
> >
> https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91
> >     <
> https://github.com/facebook/folly/blob/master/folly/logging/AsyncLogWriter.cpp#L91
> >
> >
> >     My current implementation is just in the middle two polar opinions.
> my
> >     buffer is implemented using a linkedlist-based deque. It means that I
> >     can pop elements from either sides. technically speaking, I can
> easily
> >     support 2 discard policies.
> >
> >     In CSR, I wrote the following sentence in Solution section.
> >     "On buffer exhaustion a message is discarded so that under no
> >     circumstances will logging block threads. Which message is discarded
> >     depends on implementation. In current implementation, the oldest
> message
> >     is discarded to make room for the newest message. "
> >
> >     The reason I would like to "leave to implementation" because I don't
> >     think it's a good idea to choose a discard policy in CSR. The wiggle
> >     room can give more freedom for changing different data structures and
> >     algorithms. David said we can't it undefined. If so, what's the
> discard
> >     policy HotSpot prefers?
> >
> >     We have discussed it on CSR.
> >
> https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683
> >     <
> https://bugs.openjdk.java.net/browse/JDK-8264323?focusedCommentId=14419683&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419683
> >
> >
> >     There are more audiences. Inputs are welcome.
> >
> >     FYI, current PR#3135 has implemented dropped message statistics. In
> the
> >     log files, you would find meta messages to indicate how many messages
> >     were lost. eg. line @34300:
> >     34299-[trace][metaspace              ] Metaspace::allocate: type 7
> >     return 0x00007fcf284fcb18.
> >     34300:[warning][                       ]    529 messages dropped...
> >     34301-[trace  ][metaspace              ] Arena @0x00007fcf80252df0
> >     (non-class sm): after allocation: 1 chunk(s),
> >     current:@0x00007fcf80243ef0, u, base 0x00007fcf28400000, level lv00
> >     (524288), used: 132162, committed: 139264, committed-free: 7102
> >
> >     thanks,
> >     --lx
> >
> >
> >
> >     On 3/30/21 11:18 AM, Volker Simonis wrote:
> >     > CAUTION: This email originated from outside of the organization.
> >     Do not click links or open attachments unless you can confirm the
> >     sender and know the content is safe.
> >     >
> >     >
> >     >
> >     > Hi,
> >     >
> >     > I'd like to (re)start a discussion on asynchronous logging
> [1,2,3,4].
> >     > We are successfully using this feature productively at Amazon both
> in
> >     > jdk8 and jdk11 to reduce the tail latency of services which use
> >     > logging. We think that async logging is a useful addition to the
> >     > current logging framework which might be beneficial to a wider
> range
> >     > of users. The following write-up tries to capture the comments and
> >     > suggestions from the previous discussions we are aware of.
> >     >
> >     > Current state:
> >     >
> >     > - HotSpot uses the so called "Unified Logging" (UL) framework which
> >     > was introduced by JEP 158 [5] in JDK 9. Most logs have been
> >     > retrofitted to use UL since then (e.g. "JEP 271: Unified GC
> Logging"
> >     > [6]).
> >     > - The current UL implementation is based on the standard C buffered
> >     > stream I/O interface [7]. The LogFileStreamOutput class which
> writes
> >     > logs to abstract FILE streams is the only child of the abstract
> base
> >     > class LogOutput. LogFileStreamOutput has three child classes
> >     > LogStdoutOutput,  LogStderrOutput and LogFileOutput which write to
> >     > stdout, stderr or an arbitrary file respectively. The initial UL
> JEP
> >     > 158 [5] envisioned logging to a socket but has not implemented it.
> At
> >     > least one such extension has been proposed since then [8].
> >     > - UL synchronizes logs from different threads with the help of the
> >     > standard C flockfile()/funlockfile() [9] functions. But even
> without
> >     > this explicit locking, all the "stdio functions are thread-safe.
> This
> >     > is achieved by assigning to each FILE object a lockcount and (if
> the
> >     > lockcount is nonzero) an owning thread.  For each library call,
> these
> >     > functions wait until the FILE object is no longer locked by a
> >     > different thread, then lock it, do the requested I/O, and unlock
> the
> >     > object again" [9]. A quick look at the glibc sources reveals that
> FILE
> >     > locking is implemented with the help of futex() [10] which breaks
> down
> >     > to s simple atomic compare and swap (CAS) on the fast path.
> >     > - Notice that UL "synchronizes" logs from different threads to
> avoid
> >     > log interleaving. But it does not "serialize" logs according to the
> >     > time at which  they occurred. This is because the underlying stdio
> >     > functions do not guarantee a specific order for different threads
> >     > waiting on a locked FILE stream. E.g. if three log events A, B, C
> >     > occur in that order, the first will lock the output stream. If the
> log
> >     > events B and C both arrive while the stream is locked, it is
> >     > unspecified which of B and C will be logged first after A releases
> the
> >     > lock.
> >     >
> >     > Problem statement:
> >     >
> >     > - The amount of time a log event will block its FILE stream
> depends on
> >     > the underlying file system. This can range from a few nanoseconds
> for
> >     > in-memory file systems or milliseconds for physical discs under
> heavy
> >     > load up to several seconds in the worst case scenario for e.g.
> network
> >     > file systems. A blocked log output stream will block all concurrent
> >     > threads which try to write log messages at the same time. If
> logging
> >     > is done during a safepoint, this can significantly increase the
> >     > safepoint time (e.g. several parallel GC threads trying to log at
> the
> >     > same time). We can treat stdout/stderr as special files here
> without
> >     > loss of generality.
> >     >
> >     > Proposed solution:
> >     >
> >     > Extend UL with an asynchronous logging facility. Asynchronous
> logging
> >     > will be optional and disabled by default. It should have the
> following
> >     > properties:
> >     > - If disabled (the default) asynchronous logging should have no
> >     > observable impact on logging.
> >     > - If enabled, log messages will be stored in an intermediate data
> >     > structure (e.g. a double ended queue).
> >     > - A service thread will concurrently read and remove log messages
> from
> >     > that data structure in a FIFO style and write them to the output
> >     > stream
> >     > - Storing log messages in the intermediate data structure should
> take
> >     > constant time and not longer than logging a message takes in the
> >     > traditional UL system (in general the time should be much shorter
> >     > because the actual I/O is deferred).
> >     > - Asynchronous logging trades memory overhead (i.e. the size of the
> >     > intermediate data structure) for log accuracy. This means that in
> the
> >     > unlikely case where the service thread which does the asynchronous
> >     > logging falls behind the log producing threads, some logs might be
> >     > lost. However, the probability for this to happen can be minimized
> by
> >     > increasing the configurable size of the intermediate data
> structure.
> >     > - The final output produced by asynchronous logging should be
> equal to
> >     > the output from normal logging if no messages had to be dropped.
> >     > Notice that in contrast to the traditional unified logging,
> >     > asynchronous logging will give us the possibility to not only
> >     > synchronize log events, but to optionally also serialize them
> based on
> >     > their generation time if that's desired. This is because we are in
> >     > full control of the synchronization primitives for the intermediate
> >     > data structure which stores the logs.
> >     > - If log messages had to be dropped, this should be logged in the
> log
> >     > output (e.g. "[..] 42 messages dropped due to async logging")
> >     > - Asynchronous logging should ideally be implemented in such a way
> >     > that it can be easily adapted by alternative log targets like for
> >     > example sockets in the future.
> >     >
> >     > Alternative solutions:
> >     > - It has repeatedly been suggested to place the log files into a
> >     > memory file system but we don't think this is an optimal solution.
> >     > Main memory is often a constrained resource and we don't want log
> >     > files to compete with the JVM for it in such cases.
> >     > - It has also been argued to place the log files on a fast file
> system
> >     > which is only used for logging but in containerized environments
> file
> >     > system are often virtualized and the properties of the underlying
> >     > physical devices are not obvious.
> >     > - The load on the file system might be unpredictable due to other
> >     > applications on the same host.
> >     > - All these workarounds won't work if we eventually implement
> direct
> >     > logging to a network socket as suggested in [8].
> >     >
> >     > Implementation details / POC:
> >     >
> >     > - A recent pull request [2] for JDK-8229517 [3] proposed to use a
> >     > simple deque implementation derived from HotSpot's LinkedListImpl
> >     > class for the intermediate data structure. It synchronizes access
> to
> >     > the queue with a MutexLocker which is internally implemented with
> >     > pthread_lock() and results in an atomic CAS on the fast path. So
> >     > performance-wise the locking itself is not different from the
> >     > flockfile()/funlockfile() functionality currently used by UL but
> >     > adding a log message to the deque should be constant as it
> basically
> >     > only requires a strdup(). And we could even eliminate the strdup()
> if
> >     > we'd pre-allocate a big enough array for holding the log messages
> as
> >     > proposed in the pull request [2].
> >     > - The pull pull request [2] for JDK-8229517 [3] proposed to set the
> >     > async flag as an attribute of the Xlog option which feels more
> natural
> >     > because UL configuration is traditionally done within the Xlog
> option.
> >     > But we could just as well use a global -XX flag to enable async
> >     > logging? What are your preferences here?
> >     > - The pull pull request [2] for JDK-8229517 [3] (mis)uses the
> >     > WatcherThread as service thread to concurrently process the
> >     > intermediate data structure and write the log messages out to the
> log
> >     > stream. That should definitely be changed to an independent service
> >     > thread.
> >     > - The pull pull request [2] for JDK-8229517 [3] initially proposed
> >     > that the "service thread" runs at a fixed interval to dump log
> >     > messages to the log streams. But reviewers commented that this
> should
> >     > better happen either continuously or based on the filling level of
> the
> >     > intermediate data structure. What are your preferences here?
> >     > - What are your preferences on the configuration of the
> intermediate
> >     > data structure? Should it be configured based on the maximum
> number of
> >     > log messages it can store or rather on the total size of the stored
> >     > log messages? I think that for normal runs this distinction
> probably
> >     > won't make a big difference because the size of log messages will
> >     > probably be the same on average so "number of log messages" should
> >     > always be proportional to "total size of log mesages".
> >     >
> >     > 1. Before diving into more implementation details, I'd first like
> to
> >     > reach a general consensus that asynchronous logging is a useful
> >     > feature that's worth while adding to HotSpot.
> >     >
> >     > 2. Once we agree on that, we should agree on the desired
> properties of
> >     > asynchronous logging. I've tried to collect a basic set in the
> >     > "Proposed solution" section.
> >     >
> >     > 3. If that's done as well, we can discuss various implementation
> >     > details and finally prepare new pull requests.
> >     >
> >     > Thank you and best regards,
> >     > Volker
> >     >
> >     > [1] https://bugs.openjdk.java.net/browse/JDK-8229517
> >     <https://bugs.openjdk.java.net/browse/JDK-8229517>
> >     > [2] https://github.com/openjdk/jdk/pull/3135
> >     <https://github.com/openjdk/jdk/pull/3135>
> >     > [3]
> >
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
> >     <
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html
> >
> >     > [4]
> >
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
> >     <
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html
> >
> >     > [5] https://openjdk.java.net/jeps/158
> >     <https://openjdk.java.net/jeps/158>
> >     > [6] https://openjdk.java.net/jeps/271
> >     <https://openjdk.java.net/jeps/271>
> >     > [7] https://man7.org/linux/man-pages/man3/stdio.3.html
> >     <https://man7.org/linux/man-pages/man3/stdio.3.html>
> >     > [8]
> >     https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d
> >     <https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d>
> >     > [9] https://man7.org/linux/man-pages/man3/flockfile.3.html
> >     <https://man7.org/linux/man-pages/man3/flockfile.3.html>
> >     > [10] https://man7.org/linux/man-pages/man2/futex.2.html
> >     <https://man7.org/linux/man-pages/man2/futex.2.html>
> >     >
> >
>


From xliu at openjdk.java.net  Wed May 12 19:38:56 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 12 May 2021 19:38:56 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v11]
In-Reply-To: <HXGDBUoZPBTIBZpjrvq-5-2ugUCouv5M9XWyVEkMpDA=.dd7d46cd-c0d6-4561-ba65-88c499c6dd8c@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <mqjD7WKuF3Gn3iEFv0_ZyGiRyXjN3-wR_oUUBWpcIyI=.5c6439fe-99dc-423d-8cc9-59a2518f821f@github.com>
 <YY7ekkzGSC-2vc3qMj1fcx68r34FqgJ2Nktlj0opy1w=.ce974869-c36b-4eca-bbf1-ad3fec52b87e@github.com>
 <ZVN2W9Z0_HMkh6Bz890hUhXSnKNkX-81Mu9SmKc3dtw=.8db56549-8ce9-4f8d-9f7b-26e74c6e95c5@github.com>
 <HXGDBUoZPBTIBZpjrvq-5-2ugUCouv5M9XWyVEkMpDA=.dd7d46cd-c0d6-4561-ba65-88c499c6dd8c@github.com>
Message-ID: <JKvfhGHA0MZxgFwIsLhEkHXk7uD1FkQ6Tc5XV5Qs-kA=.7ba1f590-99ea-4e55-b637-531d682f40d4@github.com>

On Fri, 7 May 2021 13:11:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I tried but I found it's  difficult not to use LogTestFixture here for async logging tests.
>>  
>> The constructor and destructor of LogTestFixture help me do the chores. 
>> Without them, I can't use this set up function.
>>   `set_log_config(TestLogFileName, "logging=debug");`
>
> I see what you mean. I have thought about this some more. 
> 
> Unfortunately this requires you to be able to initialize and shutdown async logging at arbitrary times in the middle of VM life. Which normally would not be necessary. Not a big deal, but here is a slightly different proposal (and its just a proposal, I leave it up to you if you take this):
> 
> Instead of starting up and shutting down async logging at the start/end of a test (or, instead of the TEST_OTHER_VM proposal I did earlier), how about this:
> 
> 1) Change your tests to not modify logging options. No fixture, no setup/teardown, no setup_logging(). Leave the tests passive: In the tests, you just react on those options (eg skipping AsyncLogTests if async logging is disabled)
> 2) Instead, you hand in all logging options you need from the outside via command line into the gtestLauncher. 
> 3) rename your tests to start with "Log..." like all other UL gtests. 
> 4) Then, add a gtest run configuration to the gtest jtreg wrapper: add a configuration with async=true and lots of logging. Limit on this command line the gtests to only run UL gtests ('--gtest_filter=Log*' )
> 
> This is actually very easy, I have done this for large page tests and metaspace test, among other things. See `test/hotspot/jtreg/gtest/LargePageGtests.java` or `test/hotspot/jtreg/gtest/MetaspaceGtests.java`. 
> 
> The advantage would be:
> - no need to fiddle with log options in your tests, and to reinstate them at teardown
> - no danger of accidentally disturbing other neighboring gtests, if yours is executed in parallel to others (we don't do this today but its possible).
> - You execute all logging gtests - not only yours - with both async=false and async=true, and this is a better test coverage. This would be a nice stress test for async logging.
> 
> I understand if you don't want to do this now. This would be a fine future RFE (since actually, it should be done for all UL tests, not only yours).

Interesting,  I don't know that we can trigger gtest from Jtreg with JVM options.  Nifty!

 * @run main/native GTestWrapper --gtest_filter=metaspace* -XX:MetaspaceReclaimPolicy=none

> Unfortunately this requires you to be able to initialize and shutdown async logging at arbitrary times in the middle of VM life. Which normally would not be necessary. 
Yes, I don't like that. I tried to delete LogAsyncFlusher::terminate() several times. None of them succeed. 
I am fine we don't reclaim 
I tried to make use Threads::destroy_vm() -> LogConfiguration::finalize()

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

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

From mgkwill at openjdk.java.net  Wed May 12 20:25:10 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 20:25:10 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v34]
In-Reply-To: <H2rm3R-GJV-WYWeOz9UWIJcxRO7uXb4eRMxsR_Wsaq0=.977c5515-f38d-4d29-8909-d7a0df7ac990@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <MRbMILkFGvIK1yozvcqPjCzvqxWXh3fb3j-JKq-bHpI=.73621968-3cdc-4844-8414-0d58b5a97a53@github.com>
 <H2rm3R-GJV-WYWeOz9UWIJcxRO7uXb4eRMxsR_Wsaq0=.977c5515-f38d-4d29-8909-d7a0df7ac990@github.com>
Message-ID: <wUpxnZAEx_hKhE6d-l5EBvUfP9jyDpIDpZTnmr0Z-5E=.178b1b0f-591e-4fff-8c81-4b69fe640d3d@github.com>

On Wed, 12 May 2021 16:16:01 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check large pages =< _large_page_size
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/os/linux/os_linux.cpp line 3789:
> 
>> 3787:       break;
>> 3788:     }
>> 3789:   }
> 
>> While doing some manual testing I found a problem when setting `LargePageSizeInBytes=1g`, but without having any 1g pages configured. In that case, we will turn off `UseLargePages` even if there are 2m pages configured.
>> 
>> Not sure if we should address this as part of this change or as a follow up, but I think the `hugetlbfs_sanity_check(...)` should check that at least one of the supported large pages are configured, not just the one set as the maximum large page size.
> 
> @kstefanj How about this as a solution?

Or perhaps we could do the following, if passing in each large_page size will affect shm etc.
 (os_linux.cpp at 3674):


  if (UseHugeTLBFS) {
    bool warn_on_failure = !FLAG_IS_DEFAULT(UseHugeTLBFS);
    for (size_t large_page_size = page_size; large_page_size != (size_t)os::vm_page_size();
         large_page_size = _page_sizes.next_smaller(large_page_size)) {
      if (hugetlbfs_sanity_check(warn_on_failure, large_page_size)) {
        UseSHM = false;
        return true;
      }
    }
    UseHugeTLBFS = false;
  }

instead of:
``` 
  if (UseHugeTLBFS) {
    bool warn_on_failure = !FLAG_IS_DEFAULT(UseHugeTLBFS);
    if (hugetlbfs_sanity_check(warn_on_failure, page_size)) {
      UseSHM = false;
      return true;
    }
    UseHugeTLBFS = false;
  }

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

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

From mgkwill at openjdk.java.net  Wed May 12 20:25:09 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 20:25:09 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v34]
In-Reply-To: <MRbMILkFGvIK1yozvcqPjCzvqxWXh3fb3j-JKq-bHpI=.73621968-3cdc-4844-8414-0d58b5a97a53@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <MRbMILkFGvIK1yozvcqPjCzvqxWXh3fb3j-JKq-bHpI=.73621968-3cdc-4844-8414-0d58b5a97a53@github.com>
Message-ID: <H2rm3R-GJV-WYWeOz9UWIJcxRO7uXb4eRMxsR_Wsaq0=.977c5515-f38d-4d29-8909-d7a0df7ac990@github.com>

On Wed, 12 May 2021 16:16:33 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check large pages =< _large_page_size
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

> 3787:       break;
> 3788:     }
> 3789:   }

> While doing some manual testing I found a problem when setting `LargePageSizeInBytes=1g`, but without having any 1g pages configured. In that case, we will turn off `UseLargePages` even if there are 2m pages configured.
> 
> Not sure if we should address this as part of this change or as a follow up, but I think the `hugetlbfs_sanity_check(...)` should check that at least one of the supported large pages are configured, not just the one set as the maximum large page size.

@kstefanj How about this as a solution?

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

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

From ayang at openjdk.java.net  Wed May 12 21:16:57 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 12 May 2021 21:16:57 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>
Message-ID: <xkR4gV7Nbr4mV33YI6xNIc3fXYO4BL2je21suazl5FE=.e2651e88-045e-4838-a4db-f04460c231b1@github.com>

On Fri, 7 May 2021 08:28:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments

Just some minor comments.

src/hotspot/share/gc/shared/stringdedup/stringDedup.cpp line 171:

> 169:   // Store the string in the next pre-allocated storage entry.
> 170:   oop* ref = _buffer[--_index];
> 171:   _buffer[_index] = nullptr;

It's not really needed to clear the slot with null, right?

src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp line 51:

> 49: }
> 50: 
> 51: StringDedup::Processor::~Processor() {}

Why the empty destructor? Could we just not have it?

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 92:

> 90:   GrowableArrayCHeap<TableValue, mtStringDedup> _values;
> 91: 
> 92:   void adjust_capacity(int new_length);

Nit: diff arg name in declaration and implementation, `new_length` vs `new_capacity`.

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 295:

> 293: 
> 294: protected:
> 295:   CleanupState() {}

Is it possible to use `= default` here? Just like the destructor.

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:

> 312:   size_t _bucket_index;
> 313:   size_t _shrink_index;
> 314:   bool _grow_only;

Seems unused.

src/hotspot/share/memory/universe.cpp line 1153:

> 1151:     ResolvedMethodTable::verify();
> 1152:   }
> 1153:   if (should_verify_subset(Verify_StringDedup) && StringDedup::is_enabled()) {

Maybe drop the `is_enabled()` check in the `if` to keep the consistency with other `if`s?

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

Marked as reviewed by ayang (Committer).

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

From vlivanov at openjdk.java.net  Wed May 12 21:23:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 21:23:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <PSmocMgV3zR9cXP66XUVZyJtpbutDa7EskW-CsU64yA=.df3e4540-8cc3-43ca-93e2-8ff6cdf0af3a@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
 <C5p_aLVHjo6sHpLD1s8j17tFPpYSJqZwvjB3fPAifdY=.f71211b1-d6fa-4410-ba3b-77c96b98be44@github.com>
 <PSmocMgV3zR9cXP66XUVZyJtpbutDa7EskW-CsU64yA=.df3e4540-8cc3-43ca-93e2-8ff6cdf0af3a@github.com>
Message-ID: <7uT8QeliCJCdi6fuk24JACjroSETna9Y9QxZXep8hMA=.5a392651-605e-48b9-b20f-09b2014d42da@github.com>

On Wed, 12 May 2021 14:53:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
>> 
>>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>>> 471: 
>>> 472:   // TODO mxcsr
>> 
>> Anything left to do with mxcsr?
>
> I guess this slipped through with the initial PR.
> 
> JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298
> 
> However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr
> 
> I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

Thanks for the pointers. It would be safer for now to align the behavior with the call stub.

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

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

From xliu at openjdk.java.net  Wed May 12 21:40:01 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 12 May 2021 21:40:01 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
 <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
Message-ID: <e9NhaHARhxTLFx0v4l9ALsq_HZyv__5b586st3gy4bs=.6f9af7a7-fa57-4a1d-92f5-1af1be13b754@github.com>

On Fri, 7 May 2021 08:38:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> IIUC the mechanism you signal "async"-ness to the logging callsites with is via this pointer being NULL or not, right?

yes. 
> I am not sure this is safe wrt to lost log output on termination. 

It's not safe! now it may lose a coupe of messages in race condition. I have a patch to fix that. 

> Thinking this through, one could even scratch the LogAsyncBuffer dynamic allocation and make it either a static 
global object or even an AllStatic, with all static methods. 

I tried this as well. I found it's hard. Logging sites spread the entire lifecycle of JVM. Unfortunately, async logging can't be in function without some runtime supports, such as Thread::current(), threading.  One lesson I learned from this patch is that DON'T use any runtime in such low-level module.  

Now my target is to define a clear interval. Between 2 synchronization points, async logging takes over synchronous logging. I think it's acceptable because it covers the entire "java" runtime which is concerned by Java applications. 

|JVM begin---LogAsyncFlusher::initialize()---...---LogAsyncFlusher::terminate()--JVM End|


Another bonus for this 2-point-design is that we can assume only AsyncLog Thread is doing logging I/O when async logging is in charge.  it means I can skip the FileLocker imposed by unified logging framework.

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

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

From dlong at openjdk.java.net  Wed May 12 21:41:54 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 12 May 2021 21:41:54 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation [v4]
In-Reply-To: <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>
Message-ID: <qTghFHNz4O70jsUzcZjkVCl5w3ryFlTNDT22BDChPDI=.4157ada4-2e7b-40fb-b0ed-c82f4e449ecb@github.com>

On Mon, 3 May 2021 18:45:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
>> 
>> It served quite well for many years, but it accumulated significant complexity
>> to support different corner cases over time and inevitable evolution of the JVM
>> stretched the whole approach way too much (to the point where it become almost
>> impossible to extend the analysis any further).
>> 
>> It turns out the root problem is the decision to reimplement method resolution
>> and method selection logic from scratch and to perform it on JVM internal
>> representation. It makes it very hard to reason about correctness and the
>> implementation becomes sensitive to changes in internal representation.
>> 
>> So, the main motivation for the redesign is twofold: 
>>  * reduce maintenance burden and increase confidence in the code;
>>  * unlock some long-awaited enhancements.
>> 
>> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
>> any possible enhancements are deliberately kept out of scope for the current PR.
>> (It does deliver a bit of minor enhancements front as the changes in
>> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
>> of the other changes and was not the goal of the current work.)
>> 
>> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
>> and relies on vtable/itable information to detect target method for every
>> subclass it visits. It removes all the complexity associated with method
>> resolution and method selection logic and leaves only essential logic to prepare for method selection.
>> 
>> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
>> Instead of supporting not yet linked case, it is simply ignored. It is safe to
>> skip them (treat as "effectively non-concrete") since it is guaranteed there
>> are no instances created yet. But it requires VM to check dependencies once a
>> class is linked.
>> 
>> I ended up with 2 separate dependency validation passes (when class is loaded
>> and when it is linked). To avoid duplicated work, only dependencies
>> which may be affected by class initialization state change
>> (`unique_concrete_method_4`) are visited. 
>> 
>> (I experimented with merging passes into a single pass (delay the pass until
>> linkage is over), but it severely affected other class-related dependencies and
>> relevant optimizations.code.)
>> 
>> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
>> 
>> Old implementation is kept intact for now (will be removed later) to:
>>   - JVMCI hasn't been migrated to the new implementation yet;
>>   - enable verification that 2 implementations (old and new) agree on the results;
>>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier9
>> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
>> - [x] performance testing
>>   
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover abstract method case

Looks good.

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

Marked as reviewed by dlong (Reviewer).

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

From sjohanss at openjdk.java.net  Wed May 12 21:48:01 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 12 May 2021 21:48:01 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v34]
In-Reply-To: <wUpxnZAEx_hKhE6d-l5EBvUfP9jyDpIDpZTnmr0Z-5E=.178b1b0f-591e-4fff-8c81-4b69fe640d3d@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <MRbMILkFGvIK1yozvcqPjCzvqxWXh3fb3j-JKq-bHpI=.73621968-3cdc-4844-8414-0d58b5a97a53@github.com>
 <H2rm3R-GJV-WYWeOz9UWIJcxRO7uXb4eRMxsR_Wsaq0=.977c5515-f38d-4d29-8909-d7a0df7ac990@github.com>
 <wUpxnZAEx_hKhE6d-l5EBvUfP9jyDpIDpZTnmr0Z-5E=.178b1b0f-591e-4fff-8c81-4b69fe640d3d@github.com>
Message-ID: <Lrf6o5KJ8vGlGrnq6EitYLg0IFBzCJpMHUM_ic0dNQI=.61384548-1a6e-4cba-bed0-31167cd3277e@github.com>

On Wed, 12 May 2021 20:22:17 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 3789:
>> 
>>> 3787:       break;
>>> 3788:     }
>>> 3789:   }
>> 
>>> While doing some manual testing I found a problem when setting `LargePageSizeInBytes=1g`, but without having any 1g pages configured. In that case, we will turn off `UseLargePages` even if there are 2m pages configured.
>>> 
>>> Not sure if we should address this as part of this change or as a follow up, but I think the `hugetlbfs_sanity_check(...)` should check that at least one of the supported large pages are configured, not just the one set as the maximum large page size.
>> 
>> @kstefanj How about this as a solution?
>
> Or perhaps we could do the following, if passing in each large_page size will affect shm etc.
>  (os_linux.cpp at 3674):
> 
> 
>   if (UseHugeTLBFS) {
>     bool warn_on_failure = !FLAG_IS_DEFAULT(UseHugeTLBFS);
>     for (size_t large_page_size = page_size; large_page_size != (size_t)os::vm_page_size();
>          large_page_size = _page_sizes.next_smaller(large_page_size)) {
>       if (hugetlbfs_sanity_check(warn_on_failure, large_page_size)) {
>         UseSHM = false;
>         return true;
>       }
>     }
>     UseHugeTLBFS = false;
>   }
> 
> instead of:
> ``` 
>   if (UseHugeTLBFS) {
>     bool warn_on_failure = !FLAG_IS_DEFAULT(UseHugeTLBFS);
>     if (hugetlbfs_sanity_check(warn_on_failure, page_size)) {
>       UseSHM = false;
>       return true;
>     }
>     UseHugeTLBFS = false;
>   }

I was thinking something like the latter. Possibly keeping the call as is, but in `hugetlbfs_sanity_check(...)` keep checking smaller large page sizes if the passed in doesn't pass the test. Doing so, we could add debug/info-logging if the requested page_size doesn't pass the check.

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

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

From amenkov at openjdk.java.net  Wed May 12 22:06:52 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 12 May 2021 22:06:52 GMT
Subject: RFR: 8252530: Fix inconsistencies in hotspot whitebox
In-Reply-To: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
References: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
Message-ID: <MTpjvlTSaXTwnO5PYs56YhToasPYDwkopca4MWN4Qn0=.4d18c8d1-5d7b-4fe9-ad57-5d1f6331857e@github.com>

On Fri, 7 May 2021 18:44:59 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Replace the runtime check and remove the "InVmBuild" suffix as described in the bug.

Marked as reviewed by amenkov (Reviewer).

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

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

From mchung at openjdk.java.net  Wed May 12 22:34:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 22:34:55 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
Message-ID: <gs5wpPzMnPR1L_si6beJUuRxKkv8pF-zWiuA1IljRRc=.d5a528e8-620a-49ec-9aad-e3246f437b00@github.com>

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Overall looks good to me.

src/hotspot/share/classfile/classLoaderData.cpp line 299:

> 297: }
> 298: 
> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive

`s/Weak/Non-strong/`

test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39:

> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler;
> 38: 
> 39: public class StressHiddenClasses {

Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it.
I think this can be removed as JDK-8265694 suggests.

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

Marked as reviewed by mchung (Reviewer).

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

From mgkwill at openjdk.java.net  Wed May 12 22:43:38 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 22:43:38 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v35]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <dl9UXwAlJJyf7ddyhc2Oz_j_RNs_f4Ej7hPTbcX3-oI=.4b5fd68b-9cbb-40c7-81aa-59f0fc45e654@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:

 - Check smaller LP sizes in setup
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Check large pages =< _large_page_size
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Review comments 5_12
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Remove reserve_memory_special_huge_tlbfs mods except assert
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Merge branch 'master' into update_hlp
 - Remove extranous vm_page_size check
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - kstefanj review
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Set LargePageSizeInBytes to largepage upper limit
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/2568d181...a551a5e0

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

Changes: https://git.openjdk.java.net/jdk/pull/1153/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=34
  Stats: 154 lines in 2 files changed: 92 ins; 47 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153

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

From mgkwill at openjdk.java.net  Wed May 12 22:47:15 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 22:47:15 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Reuse flags & p vars, fix enclose
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1153/files
  - new: https://git.openjdk.java.net/jdk/pull/1153/files/a551a5e0..6a00a18d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=34-35

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

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

From mgkwill at openjdk.java.net  Wed May 12 22:52:56 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 12 May 2021 22:52:56 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
Message-ID: <2y0nRYYqBU11BNiLaMjNEsMA9QLloTmMZtacklo0jCk=.9a6799d6-cef8-4278-aef7-aa15cd95e3db@github.com>

On Wed, 12 May 2021 22:47:15 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse flags & p vars, fix enclose
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

> 3526:           return true;
> 3527:         }
> 3528:       }

@kstefanj were you thinking of something more like this?

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

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

From github.com+471021+marschall at openjdk.java.net  Wed May 12 23:17:54 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Wed, 12 May 2021 23:17:54 GMT
Subject: Integrated: 8252530: Fix inconsistencies in hotspot whitebox
In-Reply-To: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
References: <sHaxzNlySTgupbXNkbphM1XqvLueHDsCA8lb0C4cmew=.b8f5c0c4-8dfc-4a12-aaea-92ce9df81b79@github.com>
Message-ID: <zk1Ag7SiB3o9FC3q55tkzy3KnSRXNEBYy5p6dEU0-08=.8f7402e3-3851-4da1-9cc2-c5070b79da61@github.com>

On Fri, 7 May 2021 18:44:59 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Replace the runtime check and remove the "InVmBuild" suffix as described in the bug.

This pull request has now been integrated.

Changeset: ab17be28
Author:    Philippe Marschall <philippe.marschall at gmail.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab17be283559ba0477bc0dcbd11dbfccf155a57f
Stats:     21 lines in 6 files changed: 4 ins; 0 del; 17 mod

8252530: Fix inconsistencies in hotspot whitebox

Reviewed-by: dholmes, amenkov

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

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

From manc at openjdk.java.net  Thu May 13 02:12:28 2021
From: manc at openjdk.java.net (Man Cao)
Date: Thu, 13 May 2021 02:12:28 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
Message-ID: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>

Hi all,

Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.

-Man

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

Commit messages:
 - Improve async handshake

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

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

From david.holmes at oracle.com  Thu May 13 02:36:54 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 May 2021 12:36:54 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
Message-ID: <1c251e41-20cd-f516-6b11-306f7f6210a1@oracle.com>

Hi Man,

On 13/05/2021 12:12 pm, Man Cao wrote:
> Hi all,
> 
> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.

I find the terminology "remote thread" to itself be confusing - what is 
remote about it? what would be non-remote?

Can you elaborate on the different roles different threads have in this 
extended handshake model please. As I understand things in the general 
case we have three threads potentially involved:
- requesting thread
- target thread
- executing thread

is the "executing thread" what you are calling a remote thread?

Thanks,
David
-----

> -Man
> 
> -------------
> 
> Commit messages:
>   - Improve async handshake
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4005/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4005&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8267079
>    Stats: 32 lines in 3 files changed: 13 ins; 0 del; 19 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4005.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4005/head:pull/4005
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From kvn at openjdk.java.net  Thu May 13 03:29:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 13 May 2021 03:29:57 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
Message-ID: <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>

On Tue, 11 May 2021 01:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from Serguei

Compiler related changes seems fine.
@dougxc,  note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV.

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

Marked as reviewed by kvn (Reviewer).

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

From chris at sageembedded.com  Thu May 13 03:58:22 2021
From: chris at sageembedded.com (Chris Cole)
Date: Wed, 12 May 2021 20:58:22 -0700
Subject: Bug in monitor locking/unlocking on ARM32 C1 due to uninitialized
 BasicObjectLock::_displaced_header
In-Reply-To: <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
Message-ID: <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>

Hi Dan,

Great, thanks! Feel free to contact me if there is anything else I can
do that is helpful.

Chris

On Wed, May 12, 2021 at 10:21 AM <daniel.daugherty at oracle.com> wrote:
>
> Hi Chris,
>
> I filed the following new bug on your behalf:
>
> JDK-8267042 bug in monitor locking/unlocking on ARM32 C1 due to
> uninitialized BasicObjectLock::_displaced_header
> https://bugs.openjdk.java.net/browse/JDK-8267042
>
> Dan
>
>
> On 5/12/21 1:02 PM, Chris Cole wrote:
> > Hi,
> >
> > Not sure if this is the appropriate place or method to report an OpenJDK
> > bug, if not please advise.
> >
> > I have discovered a bug with ARM32 C1 monitor locking/unlocking that can
> > result in deadlock. The bug was introduced with JCK-8241234 "Unify monitor
> > enter/exit runtime entries" [1]. This change introduced a call to
> > ObjectSynchronizer::quick_entry() within the logic for
> > Runtime1::monitorenter().
> > If the monitor is inflated and already owned by the current thread, then
> > ObjectSynchronizer::quick_entry() simply increments
> > ObjectMonitor::_recursions and returns. In this case
> > Runtime1::monitorenter() returns to the JIT compiled code without calling
> > "lock->set_displaced_header(markWord::unused_mark())" (see [2]). For ARM32
> > the _displaced_header field is not always initialized in JIT code before
> > calling Runtime1::monitorenter() helper. If the uninitialized value of
> > _displaced_header field on stack happens to be NULL, this causes an issue
> > because the JIT code to exit the monitor first checks for a NULL
> > _displaced_header as an indication for non-inflated recursive locking which
> > is a noop for exiting the monitor (see [3]). This means that the
> > Runtime1::monitorexit() helper is not called as required to exit this
> > inflated monitor, and the ObjectMonitor::_recursions is not decremented as
> > required. This leads to thread not unlocking the monitor when required and
> > deadlock when another thread tries to lock the monitor.
> >
> > This bug is not present on AArch64 and x86, because the displaced header is
> > initialized in JIT code with the "unlocked object header" value (which is
> > non-zero) before calling Runtime1::monitorenter() helper (see [4] and [5]).
> > Note sure about other CPU architectures.
> >
> > I see two ways to fix this.
> > 1) In ObjectSynchronizer::quick_entry() move the
> > "lock->set_displaced_header(markWord::unused_mark())" statement to before
> > the "if (owner == current)" at line 340 in share/runtime/synchronizer.cpp
> > (see [6]), so that Runtime1::monitorenter() helper logic always initializes
> > the displaced header field as was the case before JCK-8241234.
> > 2) For ARM32 add JIT code to initialize the displaced header field before
> > calling Runtime1::monitorenter() helper as done for AArch64 and x86.
> >
> > Not sure which is better (or maybe both are required for some reason I am
> > not aware of). I believe this "displacted header" on the stack can be
> > looked at by stack walkers but I am not familiar with the exact details and
> > if there are implications on this fix.
> >
> > The bug is also present in OpenJDK 11.0.10 and later (introduced by the
> > backport of JDK-8241234 [1]).
> >
> > I/my company (Sage Embedded Software) has signed the Oracle Contributor
> > Agreement (OCA) and have been granted access to JCK.
> >
> > The bug can be reproduced in my environment with the OpenJDK Community TCK
> > testing of java.io.PipedReader that deadlocks, but because reproduction of
> > the issue requires uninitialized stack field to be zero, it might not
> > happen in some environments. I have a Java test case that can reproduce
> > this issue on ARM in 32 bit mode. It is pasted inline below at the end of
> > the email. There is a "getZeroOnStack()" method that I think helps get a
> > zero into the uninitialized _displaced_header field. The test case source
> > code is copied from OpenJDK java.io.PipedReader source code and then
> > modified. It needs to be run with only C1 enabled (I am using minimal
> > variant to enforce this) and the following command line options
> > (-XX:-BackgroundCompilation -XX:CompileThreshold=500
> > -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"). The test
> > case should run and then end with "Source thread done" and "Reading
> > complete" output if the bug is not reproduced. If the monitor bug is
> > reproduced the test case will not exit and the main thread will be
> > deadlocked, with the main thread last printing "read() before wait" and
> > missing "read() after wait" and "Reading complete". If useful I can provide
> > the output of this test cause including -XX:PrintAssebly and logging that I
> > added to ObjectSynchronizer::quick_entry() that shows uninitialized
> > lock->_displaced_header and ObjectMonitor->_recursions continue to get
> > incremented (into the 1000s) as the MonitorBugTest.receive() method is
> > called in a loop.
> >
> > Please let me know if there is anything else that would be helpful. I hope
> > to become active in the OpenJDK Community. My time is a little limited at
> > the moment, so sometimes it might take a day to respond (I have 3 and 6
> > year old kids). In the coming years I expect to have additional time to be
> > more involved in the OpenJDK Community.
> >
> > Best regards,
> > Chris Cole
> > Sage Embedded Software LLC
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8241234
> > [2]
> > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L343
> > [3]
> > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L130
> > [4]
> > https://github.com/openjdk/jdk/blob/71b8ad45b4de6836e3bb2716ebf136f3f8ea2198/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp#L95
> > [5]
> > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74
> > [6]
> > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L340
> >
> > /*
> >   * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights
> > reserved.
> >   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> >   *
> >   * This code is free software; you can redistribute it and/or modify it
> >   * under the terms of the GNU General Public License version 2 only, as
> >   * published by the Free Software Foundation.  Oracle designates this
> >   * particular file as subject to the "Classpath" exception as provided
> >   * by Oracle in the LICENSE file that accompanied this code.
> >   *
> >   * This code is distributed in the hope that it will be useful, but WITHOUT
> >   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >   * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> >   * version 2 for more details (a copy is included in the LICENSE file that
> >   * accompanied this code).
> >   *
> >   * You should have received a copy of the GNU General Public License version
> >   * 2 along with this work; if not, write to the Free Software Foundation,
> >   * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> >   *
> >   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> >   * or visit www.oracle.com if you need additional information or have any
> >   * questions.
> >   */
> >
> > package com.sageembedded.test;
> >
> > import java.io.IOException;
> > import java.io.InterruptedIOException;
> >
> > /*
> >   * java -cp bin -minimal -XX:-BackgroundCompilation -XX:CompileThreshold=500
> >   *  -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"
> >   *  -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
> >   *  com.sageembedded.test.MonitorBugTest
> >   */
> > public class MonitorBugTest {
> >
> >          private static int DATA_SIZE = 1000;
> >          private static int BUFFER_SIZE = 256;
> >
> >          private char buffer[] = new char[BUFFER_SIZE];
> >          private int writeIndex = -1;
> >          private int readIndex = 0;
> >
> >          public Object lock = new Object();
> >
> >          public static void main(String[] args) {
> >                  MonitorBugTest test = new MonitorBugTest();
> >                  test.run();
> >          }
> >          private void run() {
> >                  System.out.println("Starting test");
> >
> >                  SourceThread source = new SourceThread();
> >                  source.start();
> >
> >                  try {
> >                          for (int i = 0; i < DATA_SIZE; i++) {
> >                                  read();
> >                          }
> >                  } catch (IOException e) {
> >                          e.printStackTrace();
> >                  }
> >                  System.out.println("Reading complete");
> >
> >          }
> >
> >          synchronized void receive(char data[], int offset, int length)
> > throws IOException {
> >                  while (--length >= 0) {
> >                          getZeroOnStack(offset);
> >                          receive(data[offset++]);
> >                  }
> >          }
> >
> >          private void getZeroOnStack(int offset) {
> >                  int l1;
> >                  int l2;
> >                  int l3;
> >                  int l4;
> >                  int l5;
> >                  int l6;
> >                  int l7;
> >                  int l8;
> >                  int l9;
> >                  int l10;
> >                  int l11;
> >                  int l12;
> >                  int l13;
> >                  int l14;
> >                  int l15;
> >                  int l16;
> >
> >                  l1 = 0;
> >                  l2 = 0;
> >                  l3 = 0;
> >                  l4 = 0;
> >                  l5 = 0;
> >                  l6 = 0;
> >                  l7 = 0;
> >                  l8 = 0;
> >                  l9 = 0;
> >                  l10 = 0;
> >                  l11 = 0;
> >                  l12 = 0;
> >                  l13 = 0;
> >                  l14 = 0;
> >                  l15 = 0;
> >                  l16 = 0;
> >          }
> >
> >          synchronized void receive(int c) throws IOException {
> >                  while (writeIndex == readIndex) {
> >                          notifyAll();
> >                          try {
> >                                  wait(1000);
> >                          } catch (InterruptedException e) {
> >                                  throw new InterruptedIOException();
> >                          }
> >                  }
> >                  if (writeIndex < 0) {
> >                          writeIndex = 0;
> >                          readIndex = 0;
> >                  }
> >                  buffer[writeIndex++] = (char) c;
> >                  if (writeIndex >= buffer.length) {
> >                          writeIndex = 0;
> >                  }
> >          }
> >
> >          synchronized void last() {
> >                  notifyAll();
> >          }
> >          public synchronized int read() throws IOException {
> >                  while (writeIndex < 0) {
> >                          notifyAll();
> >                          try {
> >                                  System.out.println("read() before wait");
> >                                  wait(1000);
> >                                  System.out.println("read() after wait");
> >                          } catch (InterruptedException e) {
> >                                  throw new InterruptedIOException();
> >                          }
> >                  }
> >                  int value = buffer[readIndex++];
> >                  if (readIndex >= buffer.length) {
> >                          readIndex = 0;
> >                  }
> >                  if (writeIndex == readIndex) {
> >                          writeIndex = -1;
> >                  }
> >                  return value;
> >          }
> >
> >          private class SourceThread extends Thread {
> >                  @Override
> >                  public void run() {
> >                          System.out.println("Source thread start");
> >                          char data[] = new char[DATA_SIZE];
> >                          try {
> >                                  receive(data, 0, data.length);
> >                                  last();
> >                          } catch (IOException e) {
> >                                  e.printStackTrace();
> >                          }
> >                          System.out.println("Source thread done");
> >                  }
> >          }
> > }
>

From david.holmes at oracle.com  Thu May 13 03:59:50 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 May 2021 13:59:50 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
 <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
Message-ID: <3a458466-6e48-309b-e78d-146ab4edd9d5@oracle.com>

On 13/05/2021 1:29 pm, Vladimir Kozlov wrote:
> On Tue, 11 May 2021 01:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:
>>
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Review feedback from Serguei
> 
> Compiler related changes seems fine.
> @dougxc,  note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV.

Thanks for the review Vladimir!

cc'ing Doug in case the @-notification doesn't work.

David

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

From dholmes at openjdk.java.net  Thu May 13 04:59:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 04:59:11 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v3]
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Update after merge with master
 - Merge branch 'master' into 8252685-JavaThread
 - Review feedback from Serguei
 - Merge
 - 8252685: APIs that require JavaThread should take JavaThread arguments

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

Changes: https://git.openjdk.java.net/jdk/pull/3877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=02
  Stats: 537 lines in 121 files changed: 14 ins; 30 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877

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

From vlivanov at openjdk.java.net  Thu May 13 06:04:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 06:04:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: <UKuyvOUrzbCSZWT3GAYNUCW6sFRjXthhxYpwuWL1oXQ=.fa4d1084-3e17-495e-8165-4b9e9ab18236@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <QPPzo61oXek-2ojtTnF-bEUvDcwrAgpYZ7js82NKxQU=.75ce7fa7-49da-4db1-82bf-087f1efdab3f@github.com>
 <FpIQHDTsWfnxK3nxv8jAhS6l7kf4LraPAfXHUKeDK8A=.ec55a482-fb40-4abf-9a9b-3d92e0faa3b1@github.com>
 <UKuyvOUrzbCSZWT3GAYNUCW6sFRjXthhxYpwuWL1oXQ=.fa4d1084-3e17-495e-8165-4b9e9ab18236@github.com>
Message-ID: <GY9Rnz4RmA1-zv1JSCf_nRx5bGY7OQYZx8o8eCrZ1dk=.49a32965-3a9c-4039-b136-61ee415dc53d@github.com>

On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
>> 
>>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>>> 464: 
>>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
>> 
>> Please, file an RFE to move these declarations to `MacroAssembler`.
>
> There's already an issue for that:
> https://bugs.openjdk.java.net/browse/JDK-8266257
> 
> I've upgraded the description to make it reflect the proposed move a bit more precisely.

Got it. I was confused by the bug synopsis.

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

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

From stuefe at openjdk.java.net  Thu May 13 06:09:04 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 13 May 2021 06:09:04 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <1GaDAyqOWvVq694wFltRAHzG_cw4zw3-GZ76sJfQXIo=.a11f73ea-1d67-40d1-ba2b-8b913a9b5930@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
 <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
 <1GaDAyqOWvVq694wFltRAHzG_cw4zw3-GZ76sJfQXIo=.a11f73ea-1d67-40d1-ba2b-8b913a9b5930@github.com>
Message-ID: <4hF4_EeYby8-LexjuT38nEPOJcX85W-K0K40YIM3fo8=.fae16369-a09b-4464-8c60-7b73a7fe12af@github.com>

On Mon, 10 May 2021 23:10:00 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncFlusher.cpp line 206:
>> 
>>> 204: 
>>> 205: LogAsyncFlusher* LogAsyncFlusher::instance() {
>>> 206:   if (Thread::current_or_null() != nullptr) {
>> 
>> I don't understand why this depends on the existence of a current thread? Ideally we should be able to log just fine in corner cases, e.g. when thread is detached or if we have an error (during signal handling e..g.)
>
> `LogAsyncFlusher::enqueue` needs Thread::current() to use _lock. 
> 
> void Mutex::lock_without_safepoint_check() {
>   lock_without_safepoint_check(Thread::current());
> }
> 
> 
> This check is for a very rare corner case.  This can be trigger using the following cmdline.
> `
> java -Xlog:'thread+smr=debug:file=/tmp/t.log' -Xlog:async -version
> `
> the root cause is the following code in thread
> 
> 
> void ThreadsSMRSupport::smr_delete(JavaThread *thread) {
>   elapsedTimer timer;
>   if (EnableThreadSMRStatistics) {
>     timer.start();
>   }
> 
>   wait_until_not_protected(thread);
> 
>   delete thread; // Thread::current() will trigger assert(current != __null) failed: Thread::current() called on detached thread after ~Thread()
>   if (EnableThreadSMRStatistics) {
>     timer.stop();
>     uint millis = (uint)timer.milliseconds();
>     ThreadsSMRSupport::inc_deleted_thread_cnt();
>     ThreadsSMRSupport::add_deleted_thread_times(millis);
>     ThreadsSMRSupport::update_deleted_thread_time_max(millis);
>   }
>   // logsite will crash  in async mode because we can't use Thread::current() here. 
>   log_debug(thread, smr)("tid=" UINTX_FORMAT ": ThreadsSMRSupport::smr_delete: thread=" INTPTR_FORMAT " is deleted.", os::current_thread_id(), p2i(thread));
> }

Sigh. I get it. Another example that a good logging system should be independent from the infrastructure of the surrounding system. Any chance this patch could use raw locking primitives, pthread_mutex resp. CreateMutex, without having to rewrite everything? 

Ironically I though async logging would reduce the number of log call sites where the conditions for logging are not met, by moving most of the stack out of the caller into a separate thread. But the Thread::current condition is a new limitation then compared to sync logging.

If you don't want to change the Mutex:

So you have some rare log sites which won't allow you to use asynchronous logging since you cannot use locks, and you solve this by returning NULL, which then falls back to synchronous logging? What happens if you mix synchronous and asynchronous logging like this? Does this work?

>From a code point of view your reasoning is very difficult to deduce. Can you please change this: remove the THread::current condition from the singleton getter, and add an explicit check for Thread::current at its caller site. In async mode either just omit printing any output needing Thread::current, or relegate to synchronous printing. And add a good comment there.

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

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

From stuefe at openjdk.java.net  Thu May 13 06:14:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 13 May 2021 06:14:55 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <e9NhaHARhxTLFx0v4l9ALsq_HZyv__5b586st3gy4bs=.6f9af7a7-fa57-4a1d-92f5-1af1be13b754@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
 <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
 <e9NhaHARhxTLFx0v4l9ALsq_HZyv__5b586st3gy4bs=.6f9af7a7-fa57-4a1d-92f5-1af1be13b754@github.com>
Message-ID: <NxmK009aTom0y23QaysotVG1lNGu5eXXP0BnmJ8Rga0=.5e1ed2e1-bb08-4803-a6f2-c1911545faa8@github.com>

On Wed, 12 May 2021 21:37:24 GMT, Xin Liu <xliu at openjdk.org> wrote:

> > IIUC the mechanism you signal "async"-ness to the logging callsites with is via this pointer being NULL or not, right?
> 
> yes.
> 
> > I am not sure this is safe wrt to lost log output on termination.
> 
> It's not safe! now it may lose a coupe of messages in race condition. I have a patch to fix that.
> 
> > Thinking this through, one could even scratch the LogAsyncBuffer dynamic allocation and make it either a static
> > global object or even an AllStatic, with all static methods.
> 
> I tried this as well. I found it's hard. Logging sites spread the entire lifecycle of JVM. Unfortunately, async logging can't be in function without some runtime supports, such as Thread::current(), threading. One lesson I learned from this patch is that DON'T use any runtime in such low-level module.
> 
> Now my target is to define a clear interval. Between 2 synchronization points, async logging takes over synchronous logging. I think it's acceptable because it covers the entire "java" runtime which is concerned by Java applications.
> 
> ```
> |JVM begin---LogAsyncFlusher::initialize()---...---LogAsyncFlusher::terminate()--JVM End|
> ```

That's fine.

> 
> Another bonus for this 2-point-design is that we can assume only AsyncLog Thread is doing logging I/O when async logging is in charge. it means I can skip the FileLocker imposed by unified logging framework.

Which is good, but you have to find a solution for log sites which do not fulfill conditions to be logged asynchronously, if they fall into the live phase, see my comment above.

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

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

From alanb at openjdk.java.net  Thu May 13 06:24:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:24:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
Message-ID: <xnnGBiJp_v-hOfPj6PH5hpwyh_CKDxekdiWfXVQ_dIQ=.500477c6-50ec-4a69-a71e-1f48b579b37f@github.com>

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.java.net  Thu May 13 06:24:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:24:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <D3MaVYi6Rdq6cEhXousz4fIcsEZsYj7D-MJyxP7dqKs=.221945b9-53c8-4339-9f6e-ec36dc625abe@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
 <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>
 <D3MaVYi6Rdq6cEhXousz4fIcsEZsYj7D-MJyxP7dqKs=.221945b9-53c8-4339-9f6e-ec36dc625abe@github.com>
Message-ID: <26yxlZkGUBDT2wTKQUS9koA7PZPYojY23wJvl7aTAWE=.6ac4247e-b13f-4ed1-b603-6ff1b09f526b@github.com>

On Tue, 11 May 2021 14:11:22 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.
>
> Hi Alan,
> Thanks for find this.  I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java.
> Thanks, Harold

Thanks for fixing up these tests, I didn't spot any more in the test/jdk tree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From stuefe at openjdk.java.net  Thu May 13 06:59:00 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 13 May 2021 06:59:00 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
Message-ID: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>

On Wed, 12 May 2021 19:20:15 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build on Windows.
>   
>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.

Some more remarks.

One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:
- you would not need to save LogFileOutput reference in each message
- you can keep the drop counter as part of the output buffer, which seems more natural. No need for this kv map thing.
- less lock contention between log sites going to separate output buffers.

wrt to dimensions, the AsyncBufferSize and its derived number-of-entries would be a global limit for the sum of all enqueued messages.

Cheers, Thomas

> > About synchronization: I don't understand the reasoning behind having a periodic flush. Would an implementation which just flushes if output is available not be less complex and actually better? Why make the flusher thread wake up twice a second if there is nothing to do? OTOH why wait 500ms if there is actually output to be printed?
> 
> From my observation, the character of logging events is high-frequent but low cost. Using HotSpot Monitor(the combination of pthead_mutex_t and pthread_cond_t) for an individual logging event is expensive. The cost of waking up AsyncLog thread and lock/unlock data structure would easily shadow IO jobs(fprintf), which usually are cached in libc.
> 
> My strategy is to do IO jobs in batch and amortize the cost of synchronizations. In my design, m.wait() in the following code snippet wakes up mainly due to the load of buffer is over 3/4.
> 
> ```c++
>   while (_state == ThreadState::Running) {
>     {
>       MonitorLocker m(&_lock, Mutex::_no_safepoint_check_flag);
>       m.wait(500 /* ms, timeout*/);
>     }
>     flush();
>   }
> ```
> 
> 500ms here, which was the global option `LogAsyncInterval` , serves as a **stall protector**. If Hotspot stalls for whatever reasons, AsyncLog thread still can flush messages after timeout. I think it's useful for develops who may rely on the log files to figure out what happened inside of the hanging hotspot. Without timeout parameter, AsyncLog Thread may leave messages in the buffer and never get a change to flush them if all threads stall.

Okay, I understand.

src/hotspot/share/logging/logAsyncFlusher.cpp line 39:

> 37: }
> 38: 
> 39: void LogAsyncFlusher::enqueue_impl(const AsyncLogMessage& msg) {

Could you rename this to enqueue_locked? We use this name at other places for functions which factor out locking to the caller.

src/hotspot/share/logging/logAsyncFlusher.cpp line 40:

> 38: 
> 39: void LogAsyncFlusher::enqueue_impl(const AsyncLogMessage& msg) {
> 40:   assert_lock_strong(&_lock);

Can we enqueue (so, log) from within the async logger itself? If not, add an assert here that this should not be called from the logger thread?

src/hotspot/share/logging/logAsyncFlusher.cpp line 42:

> 40:   assert_lock_strong(&_lock);
> 41: 
> 42:   if (_buffer.size() >= _buffer_max_size)  {

As mentioned in the CSR, I prefer dropping the newest message, not the oldest one. So there would be no reason to pop anything from the buffer.

src/hotspot/share/logging/logAsyncFlusher.cpp line 58:

> 56:         // or throttled by XOFF, so only dump the dropping message in Verbose mode.
> 57:         tty->print_cr("asynclog dropping message: %s", h->message());
> 58:       }

I'm not sure this is needed or sensible. If we are flooded, we would then proceed to print every dropped message to tty? So now we flood tty? 

I'd hope exhausting the output buffer is rare, and easily remedied by telling the user to increase the buffer or stop using async mode.

src/hotspot/share/logging/logAsyncFlusher.cpp line 68:

> 66:   // notify asynclog thread if occupancy is over 3/4
> 67:   size_t sz = _buffer.size();
> 68:   if (sz > (_buffer_max_size >> 2) * 3 ) {

Can you reform this to use normal division? Ideally with "0.75" appearing somewhere as a constant which is easily changeable?

src/hotspot/share/logging/logAsyncFlusher.cpp line 102:

> 100:     _stats(17 /*table_size*/) {
> 101:   if (os::create_thread(this, os::asynclog_thread)) {
> 102:     os::start_thread(this);

Here is some error handling needed if thread creation failed. UL should drop to sync mode then.

src/hotspot/share/logging/logAsyncFlusher.cpp line 106:

> 104: 
> 105:   log_info(logging)("The maximum entries of AsyncLogBuffer: " SIZE_FORMAT ", estimated memory use: " SIZE_FORMAT " bytes",
> 106:                     _buffer_max_size, AsyncLogBufferSize);

nit: how about "Asynchronous logging enabled. Buffer size: xxx entries"?

src/hotspot/share/logging/logAsyncFlusher.cpp line 135:

> 133:   LinkedListImpl<AsyncLogMessage, ResourceObj::C_HEAP, mtLogging> logs;
> 134: 
> 135:   if (with_lock) { // critical area

I think the trick to get conditional Mutexes without having separate branches is to make the MutexLocker argument itself conditional (I think you can pass NULL, in which case no locking) - then you could merge these two branches.

src/hotspot/share/logging/logAsyncFlusher.cpp line 142:

> 140:     _buffer.pop_all(&logs);
> 141:     AsyncLogMapIterator iter;
> 142:     _stats.iterate(&iter);

All this is really difficult to understand for the casual reader. Clearer naming would help:
- something like "move-list-content" instead of pop_all
- the whole point of this iteration thing is to print the dropped counters, right? A function "Print Drop Counters" would be clearer. Unless you go the one-async-buffer-per-logfileoutput-route I mentioned earlier.

-------------

Changes requested by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 13 07:05:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 13 May 2021 07:05:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v12]
In-Reply-To: <4hF4_EeYby8-LexjuT38nEPOJcX85W-K0K40YIM3fo8=.fae16369-a09b-4464-8c60-7b73a7fe12af@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <_lA17M6wjnXOtKKNhmsjQ3qrBrcv-83z2koFk0qafMc=.c2e55f92-e529-45bd-a2b3-3829a9f51a92@github.com>
 <LNhFzLe6OcB_rUtAySOd02JTOvDWe7be9jsCQszKGts=.50c13b08-2616-4bcd-8913-a4794fbc27ea@github.com>
 <1GaDAyqOWvVq694wFltRAHzG_cw4zw3-GZ76sJfQXIo=.a11f73ea-1d67-40d1-ba2b-8b913a9b5930@github.com>
 <4hF4_EeYby8-LexjuT38nEPOJcX85W-K0K40YIM3fo8=.fae16369-a09b-4464-8c60-7b73a7fe12af@github.com>
Message-ID: <RcOmwKbVBPoZlpSnxludfHenODYDt2Vyq6YoAZg1qcQ=.d1b9fcb4-1879-454b-b337-405f171c94d5@github.com>

On Thu, 13 May 2021 06:06:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> `LogAsyncFlusher::enqueue` needs Thread::current() to use _lock. 
>> 
>> void Mutex::lock_without_safepoint_check() {
>>   lock_without_safepoint_check(Thread::current());
>> }
>> 
>> 
>> This check is for a very rare corner case.  This can be trigger using the following cmdline.
>> `
>> java -Xlog:'thread+smr=debug:file=/tmp/t.log' -Xlog:async -version
>> `
>> the root cause is the following code in thread
>> 
>> 
>> void ThreadsSMRSupport::smr_delete(JavaThread *thread) {
>>   elapsedTimer timer;
>>   if (EnableThreadSMRStatistics) {
>>     timer.start();
>>   }
>> 
>>   wait_until_not_protected(thread);
>> 
>>   delete thread; // Thread::current() will trigger assert(current != __null) failed: Thread::current() called on detached thread after ~Thread()
>>   if (EnableThreadSMRStatistics) {
>>     timer.stop();
>>     uint millis = (uint)timer.milliseconds();
>>     ThreadsSMRSupport::inc_deleted_thread_cnt();
>>     ThreadsSMRSupport::add_deleted_thread_times(millis);
>>     ThreadsSMRSupport::update_deleted_thread_time_max(millis);
>>   }
>>   // logsite will crash  in async mode because we can't use Thread::current() here. 
>>   log_debug(thread, smr)("tid=" UINTX_FORMAT ": ThreadsSMRSupport::smr_delete: thread=" INTPTR_FORMAT " is deleted.", os::current_thread_id(), p2i(thread));
>> }
>
> Sigh. I get it. Another example that a good logging system should be independent from the infrastructure of the surrounding system. Any chance this patch could use raw locking primitives, pthread_mutex resp. CreateMutex, without having to rewrite everything? 
> 
> Ironically I though async logging would reduce the number of log call sites where the conditions for logging are not met, by moving most of the stack out of the caller into a separate thread. But the Thread::current condition is a new limitation then compared to sync logging.
> 
> If you don't want to change the Mutex:
> 
> So you have some rare log sites which won't allow you to use asynchronous logging since you cannot use locks, and you solve this by returning NULL, which then falls back to synchronous logging? What happens if you mix synchronous and asynchronous logging like this? Does this work?
> 
> From a code point of view your reasoning is very difficult to deduce. Can you please change this: remove the THread::current condition from the singleton getter, and add an explicit check for Thread::current at its caller site. In async mode either just omit printing any output needing Thread::current, or relegate to synchronous printing. And add a good comment there.

Thank you for reviewing. you raise the exact problem which keep me from sleeping...

> From a code point of view your reasoning is very difficult to deduce. Can you please change this: remove the THread::current condition from the singleton getter, and add an explicit check for Thread::current at its caller site. In async mode either just omit printing any output needing Thread::current, or relegate to synchronous printing. And add a good comment there.

That's exactly the current approach. It works but async logging and synchronous logging may overlap in some rare windows such as my example of `smr_delete`. 


LogAsyncFlusher* LogAsyncFlusher::instance() {
  // thread may has been detached, then Thread::current() used by Mutex is inavailable.
  // eg. ThreadsSMRSupport::smr_delete() uses log_debug() after delete thread.
  if (Thread::current_or_null() != nullptr) {
    return _instance;
  } else {
    return nullptr;
  }
}


One drawback is that I have to give up the  FileLocker optimization for the entire interval async logging(99.99% time)
for those "rare" windows :( Once I remove FileLocker for FILE*, it may get stuck when two logging writers overlap!

I am evaluating different approaches.  eg. the 2-synchronization-points design or even replace Mutex with a semaphore-based lock like [ConfigurationLock](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logConfiguration.cpp#L55)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 13 07:10:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 13 May 2021 07:10:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
Message-ID: <wVcgXbOg6PGZ5vAJ6EkgiFMGusZXVZ3vUaCJ-Ec5wgY=.a17be71a-80be-423a-974f-292ab9e4af89@github.com>

On Thu, 13 May 2021 06:30:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 42:
> 
>> 40:   assert_lock_strong(&_lock);
>> 41: 
>> 42:   if (_buffer.size() >= _buffer_max_size)  {
> 
> As mentioned in the CSR, I prefer dropping the newest message, not the oldest one. So there would be no reason to pop anything from the buffer.

copy that.  I will update it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 13 07:24:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 13 May 2021 07:24:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <wVcgXbOg6PGZ5vAJ6EkgiFMGusZXVZ3vUaCJ-Ec5wgY=.a17be71a-80be-423a-974f-292ab9e4af89@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
 <wVcgXbOg6PGZ5vAJ6EkgiFMGusZXVZ3vUaCJ-Ec5wgY=.a17be71a-80be-423a-974f-292ab9e4af89@github.com>
Message-ID: <MF5Qjibm2V79ThjujfuqT80wKIHyiVG1rDir6OZeMPE=.638f5bb5-eeaf-4b1b-a2c5-9b42d5b2795b@github.com>

On Thu, 13 May 2021 07:07:37 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncFlusher.cpp line 42:
>> 
>>> 40:   assert_lock_strong(&_lock);
>>> 41: 
>>> 42:   if (_buffer.size() >= _buffer_max_size)  {
>> 
>> As mentioned in the CSR, I prefer dropping the newest message, not the oldest one. So there would be no reason to pop anything from the buffer.
>
> copy that.  I will update it.

> One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:

That's another reason I introduce a hashmap for dropped counters.

I read you in the RFC thread about the "Global Big Lock" for all filed-based log outputs.  I know it's not scalable.I proposed to Volker splitting buffers for different outputs. Then the cost of synchronization would be effectively same as current UL. Volker countered that it wasn't an issue until users deploys many log files. it seems rare. We can leave it for future improvement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From dholmes at openjdk.java.net  Thu May 13 07:27:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 07:27:56 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
Message-ID: <qsWyA88_CjTCQjwxawPf7eTMgUySALN7_jHLi04Nz1A=.c6935617-90df-4f49-bbe4-2f4ecb756d0d@github.com>

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Hi Harold,

Big change! :) This looks good. All the removals of references to unsafe_anonymous were easy enough  to follow.

I didn't realize that cp patching and psuedo-strings were only related to VM anonymous. It is good to see all that code go as well (but hard to see if you got it all :) ). But as per comment below are we sure psuedo-strings can't be used elsewhere?

Thanks,
David

src/hotspot/share/oops/constantPool.hpp line 493:

> 491:   // object into a CONSTANT_String entry of an unsafe anonymous class.
> 492:   // Methods internally created for method handles may also
> 493:   // use pseudo-strings to link themselves to related metaobjects.

Is this comment wrong? Are psuedo-strings not used by anything now?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3974

From xliu at openjdk.java.net  Thu May 13 07:30:58 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 13 May 2021 07:30:58 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <MF5Qjibm2V79ThjujfuqT80wKIHyiVG1rDir6OZeMPE=.638f5bb5-eeaf-4b1b-a2c5-9b42d5b2795b@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
 <wVcgXbOg6PGZ5vAJ6EkgiFMGusZXVZ3vUaCJ-Ec5wgY=.a17be71a-80be-423a-974f-292ab9e4af89@github.com>
 <MF5Qjibm2V79ThjujfuqT80wKIHyiVG1rDir6OZeMPE=.638f5bb5-eeaf-4b1b-a2c5-9b42d5b2795b@github.com>
Message-ID: <alaJaImFL8qOj8NvzRf9WrPbvGOJwIUYhNs5UFFOs34=.40d2ad28-8b5c-47a2-93fe-14b0a0f71c39@github.com>

On Thu, 13 May 2021 07:22:21 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> copy that.  I will update it.
>
>> One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:
> 
> That's another reason I introduce a hashmap for dropped counters.
> 
> I read you in the RFC thread about the "Global Big Lock" for all filed-based log outputs.  I know it's not scalable.I proposed to Volker splitting buffers for different outputs. Then the cost of synchronization would be effectively same as current UL. Volker countered that it wasn't an issue until users deploys many log files. it seems rare. We can leave it for future improvement.

I think what Volker said makes sense, then `KVHashtable<LogFileOutput*, AsyncLogBuffer&>` downsized to 
`KVHashtable<LogFileOutput*, uint32_t>`...

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 13 08:08:00 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 13 May 2021 08:08:00 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
Message-ID: <2f2-tIuGEZUa8Z30qY_JhTDokXXwqdaxja6j_tA5HxY=.a214ff28-ba58-4a3f-8ee6-7f4a9c037a36@github.com>

On Thu, 13 May 2021 06:37:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 40:
> 
>> 38: 
>> 39: void LogAsyncFlusher::enqueue_impl(const AsyncLogMessage& msg) {
>> 40:   assert_lock_strong(&_lock);
> 
> Can we enqueue (so, log) from within the async logger itself? If not, add an assert here that this should not be called from the logger thread?

enqueue_impl() is private. it's not accessible from outside. 
only public member functions can be seen by clients.

> src/hotspot/share/logging/logAsyncFlusher.cpp line 102:
> 
>> 100:     _stats(17 /*table_size*/) {
>> 101:   if (os::create_thread(this, os::asynclog_thread)) {
>> 102:     os::start_thread(this);
> 
> Here is some error handling needed if thread creation failed. UL should drop to sync mode then.

make sense! I will take a look at the error handling.

> src/hotspot/share/logging/logAsyncFlusher.cpp line 135:
> 
>> 133:   LinkedListImpl<AsyncLogMessage, ResourceObj::C_HEAP, mtLogging> logs;
>> 134: 
>> 135:   if (with_lock) { // critical area
> 
> I think the trick to get conditional Mutexes without having separate branches is to make the MutexLocker argument itself conditional (I think you can pass NULL, in which case no locking) - then you could merge these two branches.

thank you for the head-up!
MutexLocker can take NULL and drive through!  definitely worth a shot. 
Interestingly, MonitorLocker can't do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From david.holmes at oracle.com  Thu May 13 08:17:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 May 2021 18:17:57 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <2f2-tIuGEZUa8Z30qY_JhTDokXXwqdaxja6j_tA5HxY=.a214ff28-ba58-4a3f-8ee6-7f4a9c037a36@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
 <2f2-tIuGEZUa8Z30qY_JhTDokXXwqdaxja6j_tA5HxY=.a214ff28-ba58-4a3f-8ee6-7f4a9c037a36@github.com>
Message-ID: <fb5742e8-74ed-3036-0f0d-52c4f1892d82@oracle.com>

On 13/05/2021 6:08 pm, Xin Liu wrote:
> thank you for the head-up!
> MutexLocker can take NULL and drive through!  definitely worth a shot.
> Interestingly, MonitorLocker can't do that.

You only need MonitorLocker if you want to use wait/notify, in which 
case NULL is not an option. :)

I've been watching the to-and-fro around the locking issues and 
Thread::current(). A Semaphore-based lock may be the cleanest solution.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From xliu at openjdk.java.net  Thu May 13 08:20:00 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 13 May 2021 08:20:00 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
Message-ID: <_H5B7zZ1H1RQgNq4wuVs_i3mg0puFQ1LssXahtETU8Y=.6877e7aa-56b6-41ac-8674-b4687cbc0a74@github.com>

On Thu, 13 May 2021 06:23:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 39:
> 
>> 37: }
>> 38: 
>> 39: void LogAsyncFlusher::enqueue_impl(const AsyncLogMessage& msg) {
> 
> Could you rename this to enqueue_locked? We use this name at other places for functions which factor out locking to the caller.

okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From tschatzl at openjdk.java.net  Thu May 13 09:00:40 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 May 2021 09:00:40 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v3]
In-Reply-To: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
Message-ID: <VkOz4kaXwS3ZwLx-eea40HUVwT_OKABZrtEBJf1Srh4=.d93d7266-7018-4855-ba23-52812054c961@github.com>

> Hi all,
> 
>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
> 
> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
> 
> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
> 
> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
> 
> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
> 
> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  kbarrett  review 2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3975/files
  - new: https://git.openjdk.java.net/jdk/pull/3975/files/288ba6dc..7988dc6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3975&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3975&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3975/head:pull/3975

PR: https://git.openjdk.java.net/jdk/pull/3975

From tschatzl at openjdk.java.net  Thu May 13 09:00:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 May 2021 09:00:42 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v2]
In-Reply-To: <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
 <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
Message-ID: <A-rDubpoRPB7_y9qabjP4Cj916PQydbsWacETXZ6USI=.fd1697c9-8fdd-419e-9504-8dfb896da02b@github.com>

On Wed, 12 May 2021 07:45:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
>> 
>> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
>> 
>> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
>> 
>> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
>> 
>> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
>> 
>> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

src/hotspot/share/gc/g1/g1RemSet.cpp line 1085:

> 1083:   G1CardTable::CardValue _dummy_card;
> 1084: 
> 1085:   ~G1MergeHeapRootsPrefetchCache() { }

Suggestion:

  ~G1MergeHeapRootsPrefetchCache() = default;

-------------

PR: https://git.openjdk.java.net/jdk/pull/3975

From mcimadamore at openjdk.java.net  Thu May 13 09:28:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 09:28:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v17]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <2Cgk9O0DjEwy44iJXmyVW_n_Q7mb0XABnlx_G8RYH0E=.f849d10a-2c74-48bc-b092-b43e37ae9574@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address CSR comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/6701654c..03662920

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15-16

  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu May 13 10:24:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:24:57 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v18]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <KXPue1AeN8mdT7MOmV7Cp4fyOB7E0nvyOtS51D_Icc0=.a7840788-b0a8-4c1b-8362-e35d9b6d330c@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/03662920..3f99cccf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16-17

  Stats: 45 lines in 15 files changed: 1 ins; 1 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu May 13 10:55:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:55:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <b-2E2SzXEoDNsbGLiHaYJgQoA4JhQHz9j9hLEyLzME4=.5e76f39e-4e08-42b7-bc23-e908f6843c03@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Rename is_entry_blob to is_optimized_entry_blob
  Rename as_entry_blob to as_optimized_entry_blob
  Fix misc typos and indentation issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3f99cccf..352c287f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17-18

  Stats: 12 lines in 7 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From vlivanov at openjdk.java.net  Thu May 13 10:55:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 10:55:42 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: <b-2E2SzXEoDNsbGLiHaYJgQoA4JhQHz9j9hLEyLzME4=.5e76f39e-4e08-42b7-bc23-e908f6843c03@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <b-2E2SzXEoDNsbGLiHaYJgQoA4JhQHz9j9hLEyLzME4=.5e76f39e-4e08-42b7-bc23-e908f6843c03@github.com>
Message-ID: <V0aycLeE9P9wnhjLVJrI4sXfLi5EZlupk9H3XJd8MVo=.2f720bc2-d199-412b-9f1f-567dc04db4e4@github.com>

On Thu, 13 May 2021 10:52:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_entry_blob to is_optimized_entry_blob
>   Rename as_entry_blob to as_optimized_entry_blob
>   Fix misc typos and indentation issues

Marked as reviewed by vlivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From vlivanov at openjdk.java.net  Thu May 13 11:02:12 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 11:02:12 GMT
Subject: Integrated: 8266074: Vtable-based CHA implementation
In-Reply-To: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
Message-ID: <-7UZAV286GR2XjsxtWGQ0dT8N5mN1VjNvksABZQk4rU=.6c7d869b-4f1c-4c4a-96eb-f697b14bf5c3@github.com>

On Tue, 27 Apr 2021 20:15:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
> 
> It served quite well for many years, but it accumulated significant complexity
> to support different corner cases over time and inevitable evolution of the JVM
> stretched the whole approach way too much (to the point where it become almost
> impossible to extend the analysis any further).
> 
> It turns out the root problem is the decision to reimplement method resolution
> and method selection logic from scratch and to perform it on JVM internal
> representation. It makes it very hard to reason about correctness and the
> implementation becomes sensitive to changes in internal representation.
> 
> So, the main motivation for the redesign is twofold: 
>  * reduce maintenance burden and increase confidence in the code;
>  * unlock some long-awaited enhancements.
> 
> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
> any possible enhancements are deliberately kept out of scope for the current PR.
> (It does deliver a bit of minor enhancements front as the changes in
> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
> of the other changes and was not the goal of the current work.)
> 
> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
> and relies on vtable/itable information to detect target method for every
> subclass it visits. It removes all the complexity associated with method
> resolution and method selection logic and leaves only essential logic to prepare for method selection.
> 
> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
> Instead of supporting not yet linked case, it is simply ignored. It is safe to
> skip them (treat as "effectively non-concrete") since it is guaranteed there
> are no instances created yet. But it requires VM to check dependencies once a
> class is linked.
> 
> I ended up with 2 separate dependency validation passes (when class is loaded
> and when it is linked). To avoid duplicated work, only dependencies
> which may be affected by class initialization state change
> (`unique_concrete_method_4`) are visited. 
> 
> (I experimented with merging passes into a single pass (delay the pass until
> linkage is over), but it severely affected other class-related dependencies and
> relevant optimizations.code.)
> 
> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
> 
> Old implementation is kept intact for now (will be removed later) to:
>   - JVMCI hasn't been migrated to the new implementation yet;
>   - enable verification that 2 implementations (old and new) agree on the results;
>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
> 
> Testing:
> - [x] hs-tier1 - hs-tier9
> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
> - [x] performance testing
>   
> Thanks!

This pull request has now been integrated.

Changeset: 127bfe44
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/127bfe44f7d09f272a08f97bfc5d168eb22474a2
Stats:     557 lines in 11 files changed: 482 ins; 6 del; 69 mod

8266074: Vtable-based CHA implementation

Reviewed-by: kvn, jrose, dlong

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Thu May 13 11:02:11 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 11:02:11 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation [v4]
In-Reply-To: <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <Y_SoTauSad16kBtr5GgfaXTP1Cs3I3fcmnRv8srn104=.b6c69356-c2b8-42d5-9f16-e17760aef3e6@github.com>
Message-ID: <PlPfBI4G9grQLFKoEkva4LF6VUcrCyj1PY8vNXB1AFI=.da4736ad-706a-4f0d-9dfb-5b5a01e25a4d@github.com>

On Mon, 3 May 2021 18:45:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
>> 
>> It served quite well for many years, but it accumulated significant complexity
>> to support different corner cases over time and inevitable evolution of the JVM
>> stretched the whole approach way too much (to the point where it become almost
>> impossible to extend the analysis any further).
>> 
>> It turns out the root problem is the decision to reimplement method resolution
>> and method selection logic from scratch and to perform it on JVM internal
>> representation. It makes it very hard to reason about correctness and the
>> implementation becomes sensitive to changes in internal representation.
>> 
>> So, the main motivation for the redesign is twofold: 
>>  * reduce maintenance burden and increase confidence in the code;
>>  * unlock some long-awaited enhancements.
>> 
>> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
>> any possible enhancements are deliberately kept out of scope for the current PR.
>> (It does deliver a bit of minor enhancements front as the changes in
>> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
>> of the other changes and was not the goal of the current work.)
>> 
>> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
>> and relies on vtable/itable information to detect target method for every
>> subclass it visits. It removes all the complexity associated with method
>> resolution and method selection logic and leaves only essential logic to prepare for method selection.
>> 
>> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
>> Instead of supporting not yet linked case, it is simply ignored. It is safe to
>> skip them (treat as "effectively non-concrete") since it is guaranteed there
>> are no instances created yet. But it requires VM to check dependencies once a
>> class is linked.
>> 
>> I ended up with 2 separate dependency validation passes (when class is loaded
>> and when it is linked). To avoid duplicated work, only dependencies
>> which may be affected by class initialization state change
>> (`unique_concrete_method_4`) are visited. 
>> 
>> (I experimented with merging passes into a single pass (delay the pass until
>> linkage is over), but it severely affected other class-related dependencies and
>> relevant optimizations.code.)
>> 
>> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
>> 
>> Old implementation is kept intact for now (will be removed later) to:
>>   - JVMCI hasn't been migrated to the new implementation yet;
>>   - enable verification that 2 implementations (old and new) agree on the results;
>>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier9
>> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
>> - [x] performance testing
>>   
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover abstract method case

Thanks for the reviews, John, Vladimir, and Dean.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From tschatzl at openjdk.java.net  Thu May 13 11:26:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 May 2021 11:26:02 GMT
Subject: RFR: 8266821: G1: Prefetch cards during merge heap roots phase
 [v2]
In-Reply-To: <iWtrpMVXx5EbGARcyji2WH4c_-YixyUg-t8c9EaVoC4=.56b59950-1f47-43d3-a56f-3dd9f01bd270@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
 <3CQhu2SB66B2xFG62ti2kVpMRTTZEp4IUdMk-7Me0ao=.25c0cc6b-fbeb-470f-976e-2fad35de7d11@github.com>
 <iWtrpMVXx5EbGARcyji2WH4c_-YixyUg-t8c9EaVoC4=.56b59950-1f47-43d3-a56f-3dd9f01bd270@github.com>
Message-ID: <n69L9_Qr-BJvk2UaYXbFh9rZwWCPMUlVXAqPckuMX7A=.7abcf737-cb23-465d-85af-5d10e06eae6c@github.com>

On Wed, 12 May 2021 14:18:54 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett review
>
> lgtm!

Thanks @walulyai @kimbarrett for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3975

From tschatzl at openjdk.java.net  Thu May 13 11:26:03 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 May 2021 11:26:03 GMT
Subject: Integrated: 8266821: G1: Prefetch cards during merge heap roots phase
In-Reply-To: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
References: <jdW_64KXPcSnUawM1CVr_onAAKWWx-zpjWZiLGLGI1I=.5c925919-9ac8-4029-b3c7-81274a07a4cb@github.com>
Message-ID: <nuPc-5krl2ZTzQsYLQTESGGG6OAzIP5j2vpBtEOXbPM=.e0a9a739-334d-444d-91e0-5d724c460577@github.com>

On Tue, 11 May 2021 13:06:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that improves performance of the merge heap roots phase in g1?
> 
> Merging heap roots (remembered sets and log buffers) into the card table for later scanning to a large degree constitutes random accesses to the card table.
> 
> Putting a small prefetch queue between calculating the card table address and inspecting the given card table value decreases merge remembered set time by 20-30% and merge log buffers time by 40-50% (on x64. AArch64 shows similar if not better improvements).
> 
> Applications not having a significant amount of either remembered sets or log buffers do not show significant difference. 
> 
> The cache size constants for arm64 and x86 were derived from testing with a benchmark creating lots of references and log buffers (i.e. BigRamTester). Could not do any corresponding tests on other architectures due to lack of machines.
> 
> Testing: tier1-3, lots of tier1-tier8 runs with [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163).

This pull request has now been integrated.

Changeset: a564f2cb
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a564f2cbd59d40df21278c5f0d785e2375b310e4
Stats:     330 lines in 9 files changed: 304 ins; 4 del; 22 mod

8266821: G1: Prefetch cards during merge heap roots phase

Reviewed-by: kbarrett, iwalulya

-------------

PR: https://git.openjdk.java.net/jdk/pull/3975

From kevinw at openjdk.java.net  Thu May 13 12:20:17 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 May 2021 12:20:17 GMT
Subject: RFR: 8266967: debug.cpp utility find() should print Java Object
 fields.
Message-ID: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>

This change enables debug.cpp's find() utility to print Java Objects with their fields.

find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on.
Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work.


Checking other uses of os::print_location this might affect:

macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64
which use os::print_location to print register contents and print words at top of stack.
These will be more verbose, as it already is in non-PRODUCT builds.

vmError uses os::print_location when showing the stack, i.e. this output:

Stack slot to memory mapping:
stack at sp + 0 slots: 0x0000000000000002 is an unknown value
..etc...

...will be more verbose when Java object references are found (for the 8 stack slots it tries to show).


Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes.


Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only:

"Executing find"
0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
{0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'

...then with the change the full info:

"Executing find"
0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
{0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
 - ---- fields (total size 13 words):
 - private 'defaultAssertionStatus' 'Z' @12  false
 - private final 'parent' 'Ljava/lang/ClassLoader;' @24  a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a
40} (ff0a0a40)
 - private final 'name' 'Ljava/lang/String;' @28  "app"{0x00000000ff0d0060} (ff0d0060)
 - private final 'unnamedModule' 'Ljava/lang/Module;' @32  a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448)
...etc...

-------------

Commit messages:
 - 8266967: debug.cpp utility find() should print Java Object fields.

Changes: https://git.openjdk.java.net/jdk/pull/4011/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4011&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266967
  Stats: 20 lines in 4 files changed: 5 ins; 12 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4011.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4011/head:pull/4011

PR: https://git.openjdk.java.net/jdk/pull/4011

From hseigel at openjdk.java.net  Thu May 13 12:31:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:31:48 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <gs5wpPzMnPR1L_si6beJUuRxKkv8pF-zWiuA1IljRRc=.d5a528e8-620a-49ec-9aad-e3246f437b00@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
 <gs5wpPzMnPR1L_si6beJUuRxKkv8pF-zWiuA1IljRRc=.d5a528e8-620a-49ec-9aad-e3246f437b00@github.com>
Message-ID: <PCK4GpTKgvSX-oiVLF3dDbEVK2REvBRO8Qi29QSd2DY=.2ba33cf9-1137-4e67-8e1a-4f9af63d98e7@github.com>

On Wed, 12 May 2021 22:30:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test changes and small fixes
>
> src/hotspot/share/classfile/classLoaderData.cpp line 299:
> 
>> 297: }
>> 298: 
>> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive
> 
> `s/Weak/Non-strong/`

fixed.  thanks for finding it.

> test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39:
> 
>> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler;
>> 38: 
>> 39: public class StressHiddenClasses {
> 
> Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it.
> I think this can be removed as JDK-8265694 suggests.

Thanks Mandy. I will remove the test as the fix for JDK-8265694 after this change is pushed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:31:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:31:44 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  fix Weak hidden comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/5246dd76..38675761

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:38:01 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:38:01 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <qsWyA88_CjTCQjwxawPf7eTMgUySALN7_jHLi04Nz1A=.c6935617-90df-4f49-bbe4-2f4ecb756d0d@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
 <qsWyA88_CjTCQjwxawPf7eTMgUySALN7_jHLi04Nz1A=.c6935617-90df-4f49-bbe4-2f4ecb756d0d@github.com>
Message-ID: <UW4SilKIKYWhjZyoRr4hj9C2u1LEozCpkijqVSA9HsA=.36d7b26a-6513-4571-84c8-5320d4e93f74@github.com>

On Thu, 13 May 2021 07:19:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix Weak hidden comment
>
> src/hotspot/share/oops/constantPool.hpp line 493:
> 
>> 491:   // object into a CONSTANT_String entry of an unsafe anonymous class.
>> 492:   // Methods internally created for method handles may also
>> 493:   // use pseudo-strings to link themselves to related metaobjects.
> 
> Is this comment wrong? Are psuedo-strings not used by anything now?

Thanks for looking at this.  I discussed pseudo strings with Coleen and we didn't find any use of them besides unsafe.DefineAnonymousClass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:50:41 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:50:41 GMT
Subject: Integrated: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <tfKcVuLeaIw0b7aQE9GDf_t4vMbAl66stRcEe6ko-Qs=.052cdc2b-7634-429e-861b-671f0bc41d80@github.com>

On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: e14b0268
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e14b0268411bba8eb01bf6c477cc8743a53ffd1c
Stats:     3754 lines in 122 files changed: 75 ins; 3426 del; 253 mod

8243287: Removal of Unsafe::defineAnonymousClass

Reviewed-by: iklam, mchung, alanb, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:50:40 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:50:40 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>
Message-ID: <sNlFAC93FzLaMQHBPf6mxME_yCgSPpP3V4MThLZ9Roo=.5d317499-eb93-4d2b-8068-7289dcc0f1f4@github.com>

On Thu, 13 May 2021 12:31:44 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Weak hidden comment

Thanks Ioi, Alan, Mandy, and David for reviewing this big change!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From kevinw at openjdk.java.net  Thu May 13 13:18:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 May 2021 13:18:00 GMT
Subject: RFR: 8266967: debug.cpp utility find() should print Java Object
 fields.
In-Reply-To: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
References: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
Message-ID: <8xu8MRlTf_YndTcXZeJ-INKnQ9TA2vVBW4GCD1bRxis=.2de1d891-76dd-4017-b46c-a7fbbf3b658a@github.com>

On Thu, 13 May 2021 12:12:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This change enables debug.cpp's find() utility to print Java Objects with their fields.
> 
> find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on.
> Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work.
> 
> 
> Checking other uses of os::print_location this might affect:
> 
> macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64
> which use os::print_location to print register contents and print words at top of stack.
> These will be more verbose, as it already is in non-PRODUCT builds.
> 
> vmError uses os::print_location when showing the stack, i.e. this output:
> 
> Stack slot to memory mapping:
> stack at sp + 0 slots: 0x0000000000000002 is an unknown value
> ..etc...
> 
> ...will be more verbose when Java object references are found (for the 8 stack slots it tries to show).
> 
> 
> Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes.
> 
> 
> Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only:
> 
> "Executing find"
> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
> 
> ...then with the change the full info:
> 
> "Executing find"
> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
>  - ---- fields (total size 13 words):
>  - private 'defaultAssertionStatus' 'Z' @12  false
>  - private final 'parent' 'Ljava/lang/ClassLoader;' @24  a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a
> 40} (ff0a0a40)
>  - private final 'name' 'Ljava/lang/String;' @28  "app"{0x00000000ff0d0060} (ff0d0060)
>  - private final 'unnamedModule' 'Ljava/lang/Module;' @32  a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448)
> ...etc...

Oops the #ifndef PRODUCT move in instanceKlass.hpp made more than just the oop printers visible,  moving it to line 1270, above print_dependent_nmethods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4011

From dnsimon at openjdk.java.net  Thu May 13 13:20:55 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 13 May 2021 13:20:55 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
 <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
Message-ID: <JM9zx8Q6rf1h-yjum1-ji-9ygGQF_cjNCRaRWmqfB7M=.bed3ed24-409c-4277-ad9c-45e5659ba2e2@github.com>

On Thu, 13 May 2021 03:26:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Compiler related changes seems fine.
> @dougxc, note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV.

I tried to test this patch against GraalVM but am blocked due to `jdk.internal.vm.compiler` [no longer being upgradeable](https://bugs.openjdk.java.net/browse/JDK-8265091?focusedCommentId=14417587&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14417587).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3877

From kevinw at openjdk.java.net  Thu May 13 13:24:17 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 May 2021 13:24:17 GMT
Subject: RFR: 8266967: debug.cpp utility find() should print Java Object
 fields. [v2]
In-Reply-To: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
References: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
Message-ID: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com>

> This change enables debug.cpp's find() utility to print Java Objects with their fields.
> 
> find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on.
> Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work.
> 
> 
> Checking other uses of os::print_location this might affect:
> 
> macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64
> which use os::print_location to print register contents and print words at top of stack.
> These will be more verbose, as it already is in non-PRODUCT builds.
> 
> vmError uses os::print_location when showing the stack, i.e. this output:
> 
> Stack slot to memory mapping:
> stack at sp + 0 slots: 0x0000000000000002 is an unknown value
> ..etc...
> 
> ...will be more verbose when Java object references are found (for the 8 stack slots it tries to show).
> 
> 
> Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes.
> 
> 
> Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only:
> 
> "Executing find"
> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
> 
> ...then with the change the full info:
> 
> "Executing find"
> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
>  - ---- fields (total size 13 words):
>  - private 'defaultAssertionStatus' 'Z' @12  false
>  - private final 'parent' 'Ljava/lang/ClassLoader;' @24  a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a
> 40} (ff0a0a40)
>  - private final 'name' 'Ljava/lang/String;' @28  "app"{0x00000000ff0d0060} (ff0d0060)
>  - private final 'unnamedModule' 'Ljava/lang/Module;' @32  a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448)
> ...etc...

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  ifdef correction

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4011/files
  - new: https://git.openjdk.java.net/jdk/pull/4011/files/10005d11..f6454294

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4011&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4011&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4011.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4011/head:pull/4011

PR: https://git.openjdk.java.net/jdk/pull/4011

From ddong at openjdk.java.net  Thu May 13 14:55:58 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 13 May 2021 14:55:58 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6]
In-Reply-To: <tbR6Z_dXTI5hlomfWcHh_Okm1jlTWrDzTYDTFvNADL8=.5313faa4-4433-431d-b51a-4f4a618a1b55@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <tbR6Z_dXTI5hlomfWcHh_Okm1jlTWrDzTYDTFvNADL8=.5313faa4-4433-431d-b51a-4f4a618a1b55@github.com>
Message-ID: <ptclF-LjMv9PvOEy0sLlEnfsaVQM-h0IvFZG1FOD9-M=.b56c4cdf-8c72-49e8-a2b7-1b3783c42331@github.com>

On Wed, 12 May 2021 17:34:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ClassLoaderData* as factor

test with this improvement:

Passed: runtime/MemberName/ResolvedMethodTableHash.java
  build: 0.587 seconds
  compile: 0.585 seconds
  main: 3.495 seconds
Test results: passed: 1


test without this improvement:

Passed: runtime/MemberName/ResolvedMethodTableHash.java
  build: 0.581 seconds
  compile: 0.579 seconds
  main: 10.896 seconds
Test results: passed: 1

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From iklam at openjdk.java.net  Thu May 13 17:03:08 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 13 May 2021 17:03:08 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v3]
In-Reply-To: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>
Message-ID: <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com>

On Thu, 13 May 2021 04:59:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Update after merge with master
>  - Merge branch 'master' into 8252685-JavaThread
>  - Review feedback from Serguei
>  - Merge
>  - 8252685: APIs that require JavaThread should take JavaThread arguments

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3877

From mandy.chung at oracle.com  Thu May 13 18:50:22 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 11:50:22 -0700
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
Message-ID: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>

I did a search on java.base and the tests on `String::indexOf` and 
`String::contains` of a slash and don't spot any such test.? The JDK has 
no use of VM anonymous class.?? If the test is trying to determine if 
it's lambda proxy class, it should be converted to call 
`Class::isHidden` but testing of the class name containing a slash is 
still valid (I haven't found any of such test though).

Mandy

On 5/11/21 6:20 AM, Brian Goetz wrote:
> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>
> Sent from my iPad
>
>> On May 11, 2021, at 8:59 AM, Harold Seigel <hseigel at openjdk.java.net> wrote:
>>
>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>
>> Thanks, Harold
>>
>> -------------
>>
>> Commit messages:
>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3974


From brian.goetz at oracle.com  Thu May 13 19:03:09 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 13 May 2021 15:03:09 -0400
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
 <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
Message-ID: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>

Thanks for checking.? I thought I remembered something like this 
somewhere, but it may be that you already fixed such tests when you did 
hidden classes?? In any case, seems like we're all good now.

Cheers,
-Brian

On 5/13/2021 2:50 PM, Mandy Chung wrote:
> I did a search on java.base and the tests on `String::indexOf` and 
> `String::contains` of a slash and don't spot any such test.? The JDK 
> has no use of VM anonymous class. If the test is trying to determine 
> if it's lambda proxy class, it should be converted to call 
> `Class::isHidden` but testing of the class name containing a slash is 
> still valid (I haven't found any of such test though).
>
> Mandy
>
> On 5/11/21 6:20 AM, Brian Goetz wrote:
>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>>
>> Sent from my iPad
>>
>>> On May 11, 2021, at 8:59 AM, Harold Seigel<hseigel at openjdk.java.net>  wrote:
>>>
>>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>>
>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>>
>>> Thanks, Harold
>>>
>>> -------------
>>>
>>> Commit messages:
>>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>>
>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files
>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8243287
>>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>>   Patch:https://git.openjdk.java.net/jdk/pull/3974.diff
>>>   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/3974/head:pull/3974
>>>
>>> PR:https://git.openjdk.java.net/jdk/pull/3974
>


From iklam at openjdk.java.net  Thu May 13 19:11:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 13 May 2021 19:11:57 GMT
Subject: RFR: 8266904: Use function pointer typedefs in
 OopOopIterateDispatch
In-Reply-To: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
References: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
Message-ID: <oeWM5PS6hvoWJK1ULpcF9YeLwobfuHJFPczykyrgoo8=.97d165da-fc5a-4f17-8700-13f12c890adf@github.com>

On Tue, 11 May 2021 19:44:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The way our OopIterateClosures are devirtualized is quite complex. I think we can lower the complexity a tiny bit by using a function pointer typedef.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3986

From mandy.chung at oracle.com  Thu May 13 20:37:34 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 13:37:34 -0700
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
 <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
 <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>
Message-ID: <b8c0d26b-6994-2f72-66e8-390e78cae7a5@oracle.com>

Maybe you were thinking 
`jdk.internal.reflect.ReflectUtil::isVMAnonymousClass` that is now 
removed by this patch [1].

[1] 
https://github.com/openjdk/jdk/pull/3974/files#diff-1af3026a3b4942af3ebe6a4df02f8952fb9d51bf93336a2f7f93ce175d047574

On 5/13/21 12:03 PM, Brian Goetz wrote:
> Thanks for checking.? I thought I remembered something like this 
> somewhere, but it may be that you already fixed such tests when you 
> did hidden classes?? In any case, seems like we're all good now.
>
> Cheers,
> -Brian
>
> On 5/13/2021 2:50 PM, Mandy Chung wrote:
>> I did a search on java.base and the tests on `String::indexOf` and 
>> `String::contains` of a slash and don't spot any such test.? The JDK 
>> has no use of VM anonymous class.?? If the test is trying to 
>> determine if it's lambda proxy class, it should be converted to call 
>> `Class::isHidden` but testing of the class name containing a slash is 
>> still valid (I haven't found any of such test though).
>>
>> Mandy
>>
>> On 5/11/21 6:20 AM, Brian Goetz wrote:
>>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>>>
>>> Sent from my iPad
>>>
>>>> On May 11, 2021, at 8:59 AM, Harold Seigel<hseigel at openjdk.java.net>  wrote:
>>>>
>>>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>>>
>>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>>>
>>>> Thanks, Harold
>>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>>>
>>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files
>>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8243287
>>>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>>>   Patch:https://git.openjdk.java.net/jdk/pull/3974.diff
>>>>   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/3974/head:pull/3974
>>>>
>>>> PR:https://git.openjdk.java.net/jdk/pull/3974
>>
>


From kbarrett at openjdk.java.net  Thu May 13 22:52:08 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 13 May 2021 22:52:08 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v3]
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <hXOVDVnjwSaQwzN0jPq_pumx21i4OHca025pWbxiNl0=.88458529-e27e-487a-bf4b-105c21a2b033@github.com>

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:

 - misc cleanups
 - refactor Requests::add
 - fix typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3662/files
  - new: https://git.openjdk.java.net/jdk/pull/3662/files/656e2426..30e7b8e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=01-02

  Stats: 69 lines in 6 files changed: 26 ins; 26 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Thu May 13 22:52:11 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 13 May 2021 22:52:11 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <xkR4gV7Nbr4mV33YI6xNIc3fXYO4BL2je21suazl5FE=.e2651e88-045e-4838-a4db-f04460c231b1@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>
 <xkR4gV7Nbr4mV33YI6xNIc3fXYO4BL2je21suazl5FE=.e2651e88-045e-4838-a4db-f04460c231b1@github.com>
Message-ID: <ObO8SzIDFF3Xhto8L1zU9M8e2o4cA61j_W1Ze4yC1rw=.19893f4d-c8d0-4fed-b9f6-c97a3556cb3e@github.com>

On Wed, 12 May 2021 21:13:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>
> Just some minor comments.

Following up on an off-line discussion with @albertnetymk , I've done a little refactoring of Requests::add.  I also made a few other small cleanups, noticed while dealing with @albertnetymk comments.  I still haven't dealt with the accumulated merge conflicts.  I'll be doing that next.

> src/hotspot/share/gc/shared/stringdedup/stringDedup.cpp line 171:
> 
>> 169:   // Store the string in the next pre-allocated storage entry.
>> 170:   oop* ref = _buffer[--_index];
>> 171:   _buffer[_index] = nullptr;
> 
> It's not really needed to clear the slot with null, right?

You are right; there used to be some asserts, but no longer. Removed.

> src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp line 51:
> 
>> 49: }
>> 50: 
>> 51: StringDedup::Processor::~Processor() {}
> 
> Why the empty destructor? Could we just not have it?

Changed to use `= default`.

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 92:
> 
>> 90:   GrowableArrayCHeap<TableValue, mtStringDedup> _values;
>> 91: 
>> 92:   void adjust_capacity(int new_length);
> 
> Nit: diff arg name in declaration and implementation, `new_length` vs `new_capacity`.

Changed to consistently use `new_capacity`

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 295:
> 
>> 293: 
>> 294: protected:
>> 295:   CleanupState() {}
> 
> Is it possible to use `= default` here? Just like the destructor.

Changed to use `= default`.

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:
> 
>> 312:   size_t _bucket_index;
>> 313:   size_t _shrink_index;
>> 314:   bool _grow_only;
> 
> Seems unused.

Removed unused `_grow_only`, left over from earlier work.

> src/hotspot/share/memory/universe.cpp line 1153:
> 
>> 1151:     ResolvedMethodTable::verify();
>> 1152:   }
>> 1153:   if (should_verify_subset(Verify_StringDedup) && StringDedup::is_enabled()) {
> 
> Maybe drop the `is_enabled()` check in the `if` to keep the consistency with other `if`s?

Done.  StringDedup::verify already does an is_enabled check.  Also fixed the description comment, which incorrectly said `is_enabled()` was a precondition.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Thu May 13 22:52:12 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 13 May 2021 22:52:12 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: <mp1Q34J8I2byMdwna1bqZL3tkCm9ImM11vZJpaLxOz0=.38771ca1-a78e-4658-9dbb-833fa5eea8be@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <BLFt3AynFf6XmrhREQXcHuAPAa_vDVFsZPjas6DH06M=.72a7c2df-f6a8-4f04-9539-4b2c13375749@github.com>
 <mp1Q34J8I2byMdwna1bqZL3tkCm9ImM11vZJpaLxOz0=.38771ca1-a78e-4658-9dbb-833fa5eea8be@github.com>
Message-ID: <JAPG0Pe26Yc35csgZzc6eehg-7zwCNRsgCcm0fb3iA0=.a9ba7e9c-e4e2-48e7-9fd2-5fb0861fc7f9@github.com>

On Wed, 12 May 2021 11:55:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>
> src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 82:
> 
>> 80: // Doing so would counteract C2 optimizations on string literals.  But an
>> 81: // interned string might later become a deduplication candidate through the
>> 82: // normal GC discovery mechanism.  To prevent such modificatoins, the
> 
> s/modificatoins/modifications

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From david.holmes at oracle.com  Fri May 14 00:06:59 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 14 May 2021 10:06:59 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v3]
In-Reply-To: <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>
 <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com>
Message-ID: <a2b55b3c-38b0-87d0-05dc-600528b7c9e0@oracle.com>

Thanks for the review Ioi!

David

On 14/05/2021 3:03 am, Ioi Lam wrote:
> On Thu, 13 May 2021 04:59:11 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
>   hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>>>
>>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>>> - Manifestations of Thread::current() become JavaThread::current()
>>> - THREAD->as_Java_thread() becomes just THREAD
>>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>>>
>>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>>>
>>> Testing:
>>>   - tiers 1-8 on Linux-x64
>>>   - all builds in tiers 1-4
>>>   - tiers 1-3 on all platforms
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>>
>>   - Update after merge with master
>>   - Merge branch 'master' into 8252685-JavaThread
>>   - Review feedback from Serguei
>>   - Merge
>>   - 8252685: APIs that require JavaThread should take JavaThread arguments
> 
> LGTM
> 
> -------------
> 
> Marked as reviewed by iklam (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3877
> 

From svkamath at openjdk.java.net  Fri May 14 02:13:58 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Fri, 14 May 2021 02:13:58 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation
 using AVX512 + VAES instructions
Message-ID: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>

I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
Performance gain of ~1.5x - 2x for message sizes 8k and above.

-------------

Commit messages:
 - Merge master
 - JDK-8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions

Changes: https://git.openjdk.java.net/jdk/pull/4019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267125
  Stats: 1017 lines in 21 files changed: 983 ins; 11 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019

PR: https://git.openjdk.java.net/jdk/pull/4019

From stuefe at openjdk.java.net  Fri May 14 03:29:37 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 14 May 2021 03:29:37 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
Message-ID: <nm8JH__rQ9-Gbt0AMGHmsbQKQ4mzXhYTQPJF2JxHnXg=.95bb8bbe-14d5-4044-b0d7-2d60a27c1239@github.com>

On Thu, 29 Apr 2021 04:50:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.
> 
> Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in various data holder structures which all are named somewhat similarly and all do a very similar job. In particular, we have:
> 
> - MetaspaceSizesSnapshot (used for gc logs)
> - MetaspaceSnapshot (used in NMT)
> - MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
> - MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
> - CompressedKlassSpacePool and MetaspacePool (used for MXBeans)
> 
> As much as possible coding should be unified.
> 
> In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).
> 
> -----------------------
> 
> This patch introduces two new data holder structures:
> - `MetaspaceStats` holds reserved/committed/used counter
> - `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.
> 
> Furthermore, the patch introduces two new APIs in MetaspaceUtils:
> - `MetaspaceStats get_statistics(type)`
> - `MetaspaceCombinedStats get_combined_statistics()`
> The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.
> 
> The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:
> 
> - GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.
> 
> - NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
>    - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
>    - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
>    - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).
> 
> - jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
> 	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
> 	- I simplified the counter coding a lot. I think the complexity was not needed.
> 	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.
> 
> - `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 
> 
> - JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
> 	- I completely removed `MetaspaceSizes`
> 	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`
> 
> - MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.
> 
> - Added a simple gtest for the new APIs
> 
> Tests: 
> - manually executed hotspot tier1 tests
> - explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
> - SAP nightlies ran on all our platforms

Gentle ping.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3786

From stuefe at openjdk.java.net  Fri May 14 04:22:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 14 May 2021 04:22:40 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <2f2-tIuGEZUa8Z30qY_JhTDokXXwqdaxja6j_tA5HxY=.a214ff28-ba58-4a3f-8ee6-7f4a9c037a36@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
 <2f2-tIuGEZUa8Z30qY_JhTDokXXwqdaxja6j_tA5HxY=.a214ff28-ba58-4a3f-8ee6-7f4a9c037a36@github.com>
Message-ID: <bfBviEJ6-OxbK1PkD02szIY36a1qAnFCwKzzwZLUO6A=.874d859d-44cf-44e4-abf7-b9abbfd72ebd@github.com>

On Thu, 13 May 2021 07:39:21 GMT, Xin Liu <xliu at openjdk.org> wrote:

> enqueue_impl() is private. it's not accessible from outside.
> only public member functions can be seen by clients.

What I meant is, can logging - hence enqueing - be done from the async thread itself? Can it happen that the logger thread itself logs, would that be a problem, and if yes, should we guard against it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From stuefe at openjdk.java.net  Fri May 14 04:49:39 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 14 May 2021 04:49:39 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <alaJaImFL8qOj8NvzRf9WrPbvGOJwIUYhNs5UFFOs34=.40d2ad28-8b5c-47a2-93fe-14b0a0f71c39@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
 <wVcgXbOg6PGZ5vAJ6EkgiFMGusZXVZ3vUaCJ-Ec5wgY=.a17be71a-80be-423a-974f-292ab9e4af89@github.com>
 <MF5Qjibm2V79ThjujfuqT80wKIHyiVG1rDir6OZeMPE=.638f5bb5-eeaf-4b1b-a2c5-9b42d5b2795b@github.com>
 <alaJaImFL8qOj8NvzRf9WrPbvGOJwIUYhNs5UFFOs34=.40d2ad28-8b5c-47a2-93fe-14b0a0f71c39@github.com>
Message-ID: <uMZz9vBq2zyxykSYutZ5VEj9eyJzGF30a4qiB2sdhNk=.1640a034-deaf-4ebf-b3e2-14cf2caf0446@github.com>

On Thu, 13 May 2021 07:28:27 GMT, Xin Liu <xliu at openjdk.org> wrote:

>>> One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:
>> 
>> That's another reason I introduce a hashmap for dropped counters.
>> 
>> I read you in the RFC thread about the "Global Big Lock" for all filed-based log outputs.  I know it's not scalable.I proposed to Volker splitting buffers for different outputs. Then the cost of synchronization would be effectively same as current UL. Volker countered that it wasn't an issue until users deploys many log files. it seems rare. We can leave it for future improvement.
>
> I think what Volker said makes sense, then `KVHashtable<LogFileOutput*, AsyncLogBuffer&>` downsized to 
> `KVHashtable<LogFileOutput*, uint32_t>`...

> > One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:
> 
> That's another reason I introduce a hashmap for dropped counters.
> 
> I read you in the RFC thread about the "Global Big Lock" for all filed-based log outputs. I know it's not scalable.I proposed to Volker splitting buffers for different outputs. Then the cost of synchronization would be effectively same as current UL. Volker countered that it wasn't an issue until users deploys many log files. it seems rare. We can leave it for future improvement.

Performance was not my main reason for suggesting this, but code simplicity.

Im fine with leaving this for a future RFE

Fior the record, here is the idea:
- keep async buffer, drop counter and async buffer lock as members in LogFileOutput
- have a global counter "enqueued-items"
- in LogFileOutput::write:
  - if enqueued-items=max, increase the drop counter in LogFileOutput
  - otherwise create buffer if needed, then enqueue into this buffer, increase global enqueued-items counter
- LogAsyncFlusher::flush becomes LogFileOutput::flush_async_buffer() or similar and:
  - prints its drop counter, if > 0
  - flushes its own buffer, same logic as today, but locks over its local _async_buffer_log
  - and decreases global enqueued-items counter
- flushing means iterating over all LogFileOutput objects and calling flush on them.


> I think what Volker said makes sense, then `KVHashtable<LogFileOutput*, AsyncLogBuffer&>` downsized to
> `KVHashtable<LogFileOutput*, uint32_t>`...

I'm loosing track here, where is Volker's remark and where is the first variant used?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From kbarrett at openjdk.java.net  Fri May 14 04:31:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 04:31:59 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v4]
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <IhganH3OvJTx-vLN0t3WBTpisPsFuj8qrueA9d3C31A=.2bee0cf4-8e7a-4a1d-a0e3-9cb09665d2c3@github.com>

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into new_dedup2
 - misc cleanups
 - refactor Requests::add
 - fix typo
 - more comment improvements
 - improve naming and comments around injected String flags
 - fix some typos in comments
 - New string deduplication

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=03
  Stats: 6191 lines in 104 files changed: 2369 ins; 3204 del; 618 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Fri May 14 05:10:38 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 05:10:38 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v4]
In-Reply-To: <IhganH3OvJTx-vLN0t3WBTpisPsFuj8qrueA9d3C31A=.2bee0cf4-8e7a-4a1d-a0e3-9cb09665d2c3@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <IhganH3OvJTx-vLN0t3WBTpisPsFuj8qrueA9d3C31A=.2bee0cf4-8e7a-4a1d-a0e3-9cb09665d2c3@github.com>
Message-ID: <r-ongOitdOyKigoDr3ib3dxXVMjF5vaR5rSzLUziP48=.11586250-4d1a-45fa-a7dd-e0e71536fb7d@github.com>

On Fri, 14 May 2021 04:31:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into new_dedup2
>  - misc cleanups
>  - refactor Requests::add
>  - fix typo
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments
>  - New string deduplication

The "merge from master" commit (ccb9951) doesn't build with Shenandoah.  I've asked Zhengyu to take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From ayang at openjdk.java.net  Fri May 14 07:05:41 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 May 2021 07:05:41 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods [v2]
In-Reply-To: <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
 <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>
Message-ID: <opQ9ohCA0U-DCsEm2DtS79qFA34hec24v9k6PEQhxxs=.9081be71-8e25-4818-a118-e5ac63e2577c@github.com>

On Tue, 11 May 2021 10:48:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Adding the assertion, and fixing a benign violation.
>> 
>> Test: tier1-7; no violation of this assertion.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge master
>  - delta

Rerun tier1-7 after the merge; no violation of the new assertion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3900

From stefank at openjdk.java.net  Fri May 14 07:58:48 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 14 May 2021 07:58:48 GMT
Subject: RFR: 8266904: Use function pointer typedefs in
 OopOopIterateDispatch
In-Reply-To: <HQxHVaj5KhVqOkRasHtJUdOs8uOWEvpt_ARwGy2lbhQ=.e0772c65-fc44-4794-bf51-17c293b5313f@github.com>
References: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
 <HQxHVaj5KhVqOkRasHtJUdOs8uOWEvpt_ARwGy2lbhQ=.e0772c65-fc44-4794-bf51-17c293b5313f@github.com>
Message-ID: <5fE7EXaYwtG5O765_CbwILS4YB0cwFTuUOVzjW5xsl4=.a83af116-d1b2-4da7-b837-1f8fa415e28d@github.com>

On Wed, 12 May 2021 11:33:15 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> The way our OopIterateClosures are devirtualized is quite complex. I think we can lower the complexity a tiny bit by using a function pointer typedef.
>
> Lgtm.

Thanks for reviewing @tschatzl and @iklam!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3986

From stefank at openjdk.java.net  Fri May 14 07:58:48 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 14 May 2021 07:58:48 GMT
Subject: Integrated: 8266904: Use function pointer typedefs in
 OopOopIterateDispatch
In-Reply-To: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
References: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com>
Message-ID: <JkQHfH2ApWFa3kVRtYWpfN3deNDRSVtbRoKiAtK7Nus=.39d69b3f-5895-4af6-8c4e-57a91845cecc@github.com>

On Tue, 11 May 2021 19:44:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The way our OopIterateClosures are devirtualized is quite complex. I think we can lower the complexity a tiny bit by using a function pointer typedef.

This pull request has now been integrated.

Changeset: 88907bb8
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/88907bb81a5a67a51f32c36f6cd821c2488117eb
Stats:     12 lines in 1 file changed: 6 ins; 0 del; 6 mod

8266904: Use function pointer typedefs in OopOopIterateDispatch

Reviewed-by: tschatzl, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/3986

From stuefe at openjdk.java.net  Fri May 14 09:45:39 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 14 May 2021 09:45:39 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
Message-ID: <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>

On Wed, 12 May 2021 22:47:15 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse flags & p vars, fix enclose
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Hi,

we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java. 

#
#  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
#  assert(div != 0) failed: lcm requires positive arguments
#


Stack:


V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec


Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From vlivanov at openjdk.java.net  Fri May 14 10:05:59 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 14 May 2021 10:05:59 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6]
In-Reply-To: <tbR6Z_dXTI5hlomfWcHh_Okm1jlTWrDzTYDTFvNADL8=.5313faa4-4433-431d-b51a-4f4a618a1b55@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <tbR6Z_dXTI5hlomfWcHh_Okm1jlTWrDzTYDTFvNADL8=.5313faa4-4433-431d-b51a-4f4a618a1b55@github.com>
Message-ID: <LJ4VcHC-bukDkH6ru2JQnRfJV7mkw1wQvCKCRi-bPA0=.925967cd-be03-46b4-8c1d-289fb72b4ec9@github.com>

On Wed, 12 May 2021 17:34:25 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ClassLoaderData* as factor

What about the following variant?


diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp
index 6fd5b9b8203..f1f1c82f591 100644
--- a/src/hotspot/share/classfile/classLoaderData.hpp
+++ b/src/hotspot/share/classfile/classLoaderData.hpp
@@ -325,6 +325,11 @@ class ClassLoaderData : public CHeapObj<mtClass> {
   const char* loader_name_and_id() const;
   Symbol* name_and_id() const { return _name_and_id; }
 
+  unsigned identity_hash() const {
+    unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
+    return addr_bits;
+  }
+
   JFR_ONLY(DEFINE_TRACE_ID_METHODS;)
 };
 
diff --git a/src/hotspot/share/prims/resolvedMethodTable.cpp b/src/hotspot/share/prims/resolvedMethodTable.cpp
index 5e5761094f1..527a39f3646 100644
--- a/src/hotspot/share/prims/resolvedMethodTable.cpp
+++ b/src/hotspot/share/prims/resolvedMethodTable.cpp
@@ -23,6 +23,7 @@
  */
 
 #include "precompiled.hpp"
+#include "classfile/classLoaderData.hpp"
 #include "classfile/javaClasses.hpp"
 #include "gc/shared/oopStorage.inline.hpp"
 #include "gc/shared/oopStorageSet.hpp"
@@ -53,7 +54,8 @@ static const size_t GROW_HINT = 32;
 static const size_t ResolvedMethodTableSizeLog = 10;
 
 unsigned int method_hash(const Method* method) {
-  unsigned int hash = method->klass_name()->identity_hash();
+  unsigned int hash = method->method_holder()->class_loader_data()->identity_hash();
+  hash = (hash * 31) ^ method->klass_name()->identity_hash();
   hash = (hash * 31) ^ method->name()->identity_hash();
   hash = (hash * 31) ^ method->signature()->identity_hash();
   return hash;

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From github.com+4146708+a74nh at openjdk.java.net  Fri May 14 11:31:26 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 14 May 2021 11:31:26 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
Message-ID: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>

On PAC systems, native code may sign return addresses before saving
them to the stack. We must ensure we strip the any signed bits in
order to walk the stack.
Add extra asserts in places where we do not expect saved return
addresses to be signed.

On non-PAC systems, all PAC instructions are treated as NOPs.

On Apple, use the provided ptrauth interface instead of asm
as the compiler may optimise further.

Fedora 33 compiles all distro packages using PAC. Running the distro
provided OpenJDK-latest in GDB on a PAC system:

Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
   from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
(gdb) call (int)pns($sp, $fp, $pc)

"Executing pns"
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe26fe4]  init_globals()+0x10
C  0x006ffffff74750c4
C  0x0042fffff6a7f84c
C  0x0037fffff7fa0954
C  0x0030fffff7fa4540
C  0x0078fffff7d980c8

OpenJDK with this patch at the same breakpoint:

(gdb) call (int)pns($sp, $fp, $pc)
"Executing pns"
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
C  [libjli.so+0x3860]  JavaMain+0x7c
C  [libjli.so+0x732c]  ThreadJavaMain+0xc
C  [libpthread.so.0+0x80c8]  start_thread+0xd8

OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:

"Executing pns"
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
v  ~StubRoutines::call_stub
V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
j  java.lang.System.initPhase2(ZZ)I+0 java.base
v  ~StubRoutines::call_stub
V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
C  [libjli.so+0x3860]  JavaMain+0x7c
C  [libjli.so+0x732c]  ThreadJavaMain+0xc
C  [libpthread.so.0+0x80c8]  start_thread+0xd8

-------------

Commit messages:
 - 8266749: AArch64: Fix backtracing on PAC enabled systems

Changes: https://git.openjdk.java.net/jdk/pull/4029/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266749
  Stats: 78 lines in 3 files changed: 76 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4029.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4029/head:pull/4029

PR: https://git.openjdk.java.net/jdk/pull/4029

From ddong at openjdk.java.net  Fri May 14 12:04:56 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 14 May 2021 12:04:56 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6]
In-Reply-To: <LJ4VcHC-bukDkH6ru2JQnRfJV7mkw1wQvCKCRi-bPA0=.925967cd-be03-46b4-8c1d-289fb72b4ec9@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <tbR6Z_dXTI5hlomfWcHh_Okm1jlTWrDzTYDTFvNADL8=.5313faa4-4433-431d-b51a-4f4a618a1b55@github.com>
 <LJ4VcHC-bukDkH6ru2JQnRfJV7mkw1wQvCKCRi-bPA0=.925967cd-be03-46b4-8c1d-289fb72b4ec9@github.com>
Message-ID: <RgDwedQgEhm0u6a66K5a-H1Scf_8fK0jV3Af-usNMzI=.e44f34c5-9efe-4b91-baaf-4aea44d035f3@github.com>

On Fri, 14 May 2021 10:02:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ClassLoaderData* as factor
>
> What about the following variant?
> 
> 
> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp
> index 6fd5b9b8203..f1f1c82f591 100644
> --- a/src/hotspot/share/classfile/classLoaderData.hpp
> +++ b/src/hotspot/share/classfile/classLoaderData.hpp
> @@ -325,6 +325,11 @@ class ClassLoaderData : public CHeapObj<mtClass> {
>    const char* loader_name_and_id() const;
>    Symbol* name_and_id() const { return _name_and_id; }
>  
> +  unsigned identity_hash() const {
> +    unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
> +    return addr_bits;
> +  }
> +
>    JFR_ONLY(DEFINE_TRACE_ID_METHODS;)
>  };
>  
> diff --git a/src/hotspot/share/prims/resolvedMethodTable.cpp b/src/hotspot/share/prims/resolvedMethodTable.cpp
> index 5e5761094f1..527a39f3646 100644
> --- a/src/hotspot/share/prims/resolvedMethodTable.cpp
> +++ b/src/hotspot/share/prims/resolvedMethodTable.cpp
> @@ -23,6 +23,7 @@
>   */
>  
>  #include "precompiled.hpp"
> +#include "classfile/classLoaderData.hpp"
>  #include "classfile/javaClasses.hpp"
>  #include "gc/shared/oopStorage.inline.hpp"
>  #include "gc/shared/oopStorageSet.hpp"
> @@ -53,7 +54,8 @@ static const size_t GROW_HINT = 32;
>  static const size_t ResolvedMethodTableSizeLog = 10;
>  
>  unsigned int method_hash(const Method* method) {
> -  unsigned int hash = method->klass_name()->identity_hash();
> +  unsigned int hash = method->method_holder()->class_loader_data()->identity_hash();
> +  hash = (hash * 31) ^ method->klass_name()->identity_hash();
>    hash = (hash * 31) ^ method->name()->identity_hash();
>    hash = (hash * 31) ^ method->signature()->identity_hash();
>    return hash;

@iwanowww 
It's okay for me, updated.

Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From ddong at openjdk.java.net  Fri May 14 12:04:55 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 14 May 2021 12:04:55 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <b2K9D0KPJhFyIlkdP2hxuNsC1F4P4b56_C0a7925gww=.b7a50ca2-1f96-434b-a9a1-d5709af1a5bb@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  refactor

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/c7c54ae2..b02705f0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=05-06

  Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3901.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901

PR: https://git.openjdk.java.net/jdk/pull/3901

From vlivanov at openjdk.java.net  Fri May 14 12:34:36 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 14 May 2021 12:34:36 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7]
In-Reply-To: <b2K9D0KPJhFyIlkdP2hxuNsC1F4P4b56_C0a7925gww=.b7a50ca2-1f96-434b-a9a1-d5709af1a5bb@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <b2K9D0KPJhFyIlkdP2hxuNsC1F4P4b56_C0a7925gww=.b7a50ca2-1f96-434b-a9a1-d5709af1a5bb@github.com>
Message-ID: <2iWHZyXol0hYutYUXe4KGOdq2sw2x-dn0iAhDzByfTo=.d855fc67-247c-4e2d-8861-fddb6bddf2bf@github.com>

On Fri, 14 May 2021 12:04:55 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor

Looks good to me, but, please, wait for somebody from Runtime team to approve it.

src/hotspot/share/prims/resolvedMethodTable.cpp line 56:

> 54: 
> 55: unsigned int method_hash(const Method* method) {
> 56:   unsigned int hash = method->method_holder()->class_loader_data()->identity_hash();

I don't see "#include classfile/classLoaderData.hpp" in your patch. Did you verify it builds successfully? I saw a compilation failure without the include:


src/hotspot/share/prims/resolvedMethodTable.cpp:56:67: error: member access into incomplete type 'ClassLoaderData'
  unsigned int hash = method->method_holder()->class_loader_data()->identity_hash();
                                                                  ^
src/hotspot/share/memory/allocation.hpp:260:7: note: forward declaration of 'ClassLoaderData'
class ClassLoaderData;
      ^
1 error generated.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3901

From zgu at openjdk.java.net  Fri May 14 12:43:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 14 May 2021 12:43:53 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v4]
In-Reply-To: <IhganH3OvJTx-vLN0t3WBTpisPsFuj8qrueA9d3C31A=.2bee0cf4-8e7a-4a1d-a0e3-9cb09665d2c3@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <IhganH3OvJTx-vLN0t3WBTpisPsFuj8qrueA9d3C31A=.2bee0cf4-8e7a-4a1d-a0e3-9cb09665d2c3@github.com>
Message-ID: <OfLLYd80v7U4EzIJczqUk5mJcToR9gvf_w841_ucBVU=.6d88d61e-3c5e-4ad7-85e6-b5607de01efb@github.com>

On Fri, 14 May 2021 04:31:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into new_dedup2
>  - misc cleanups
>  - refactor Requests::add
>  - fix typo
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments
>  - New string deduplication

> The "merge from master" commit ([ccb9951](https://github.com/openjdk/jdk/commit/ccb99515d020785d7fe1cf9a1c247aeed775dc19)) doesn't build with Shenandoah. I've asked Zhengyu to take a look.

Just missing a parameter:

```diff --git a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
index ddaa66ccc14..93a067fa22d 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
@@ -57,7 +57,7 @@ ShenandoahInitMarkRootsClosure::ShenandoahInitMarkRootsClosure(ShenandoahObjToSc
 
 template <class T>
 void ShenandoahInitMarkRootsClosure::do_oop_work(T* p) {
-  ShenandoahMark::mark_through_ref<T, NO_DEDUP>(p, _queue, _mark_context, false);
+  ShenandoahMark::mark_through_ref<T, NO_DEDUP>(p, _queue, _mark_context, NULL, false);
 }```

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:

> 312:   size_t _bucket_index;
> 313:   size_t _shrink_index;
> 314:   bool _grow_only;

Indentation

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From tschatzl at openjdk.java.net  Fri May 14 12:59:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 14 May 2021 12:59:48 GMT
Subject: RFR: 8267153: Problemlist
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise
 from CI
Message-ID: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>

Hi,
  can I have reviews for this small change that problemlists jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove noise from the CI.

Thanks,
  Thomas

-------------

Commit messages:
 - Problemlist test case

Changes: https://git.openjdk.java.net/jdk/pull/4031/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4031&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267153
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4031.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4031/head:pull/4031

PR: https://git.openjdk.java.net/jdk/pull/4031

From aph at openjdk.java.net  Fri May 14 13:14:37 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 14 May 2021 13:14:37 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <cz45_zpHWEkLSXsCH7C0zmJWDGV5gCAIEKLqs4D2is8=.08fc2fc6-83b6-48f7-9f68-be67ade893ec@github.com>

On Fri, 14 May 2021 11:22:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

src/hotspot/cpu/aarch64/pauth_aarch64.hpp line 3:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2021, Arm Limited. All rights reserved.

This file is not a derived work of Oracle's, as far as I can see.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Fri May 14 13:22:35 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 14 May 2021 13:22:35 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <XGHsqiLcZ14LZd1xSaiBiQ4RpLeZOBHjxswvv3xVUWQ=.55946252-4092-459d-be2c-5a24839bff27@github.com>

On Fri, 14 May 2021 11:22:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

Windows build is failing because it doesn't like volatile:
d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\pauth_aarch64.hpp(43): error C2059: syntax error: 'volatile'

I guess the fix is to put pauth_aarch64.hpp into the os_arch/ directories. I wanted to avoid that because each copy would be almost identical. Unless anyone has any better ideas?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From coleenp at openjdk.java.net  Fri May 14 13:30:49 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 14 May 2021 13:30:49 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7]
In-Reply-To: <b2K9D0KPJhFyIlkdP2hxuNsC1F4P4b56_C0a7925gww=.b7a50ca2-1f96-434b-a9a1-d5709af1a5bb@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <b2K9D0KPJhFyIlkdP2hxuNsC1F4P4b56_C0a7925gww=.b7a50ca2-1f96-434b-a9a1-d5709af1a5bb@github.com>
Message-ID: <ptWd5DHQyKqQUbZBpdIk4cCR7HGgho3xn2XO4PU1_3c=.c1317a5f-c586-4ff3-8ade-81dc49396ec6@github.com>

On Fri, 14 May 2021 12:04:55 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor

Looks good to me, with the inclusion of classLoaderData.hpp in resolvedMethodTable.hpp.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3901

From mgkwill at openjdk.java.net  Fri May 14 14:40:44 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 14 May 2021 14:40:44 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
 <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>
Message-ID: <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>

On Fri, 14 May 2021 09:42:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java.
> 
> ```
> #
> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
> #  assert(div != 0) failed: lcm requires positive arguments
> #
> ```
> 
> Stack:
> 
> ```
> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
> ```
> 
> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?

Thanks @tstuefe. Taking a look now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From vkempik at openjdk.java.net  Fri May 14 14:52:35 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 14 May 2021 14:52:35 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>

On Fri, 14 May 2021 11:22:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

let me check with macos/aarch64 on macos11.4b as it was giving problems with return address having pac signature sometimes too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From dcubed at openjdk.java.net  Fri May 14 15:19:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 15:19:38 GMT
Subject: RFR: 8267153: Problemlist
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise
 from CI
In-Reply-To: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
References: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
Message-ID: <LoeR9_QQtxUzj2tfpdPoXtihy5npKhaexWLqwMoCgzk=.83594fae-5613-4504-a8df-f36c8c6f2332@github.com>

On Fri, 14 May 2021 12:20:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
>   can I have reviews for this small change that problemlists jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove noise from the CI.
> 
> Thanks,
>   Thomas

Thumbs up. This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4031

From mgkwill at openjdk.java.net  Fri May 14 15:19:44 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 14 May 2021 15:19:44 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
Message-ID: <hlj2f_astzwwPpq4-x47spHmo-iKNTdOpvKvJuy5uI8=.34b442a1-cc03-4620-b576-8f1c6cfd655c@github.com>

On Wed, 12 May 2021 22:47:15 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse flags & p vars, fix enclose
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/os/linux/os_linux.cpp line 3616:

> 3614:   //
> 3615:   // If we can't determine the value (e.g. /proc is not mounted, or the text
> 3616:   // format has been changed), we'll set largest page size to 0

I have a suspicion that this section change is causing the issue @tstuefe is seeing on linux ppc64. I think we are setting `size_t default_large_page_size = 0;` and then attempting an **unfruitful scan of /proc/meminfo**.

Later we get `alignment` using `lcm` in 
https://github.com/openjdk/jdk/blob/16ca370f1ac933a6aef49bd147d985e66b4c8930/src/hotspot/share/gc/shared/gcArguments.cpp#L81

https://github.com/openjdk/jdk/blob/af4cd04c2e393f8d1ffef60f49e3269adee649b8/src/hotspot/share/utilities/globalDefinitions.cpp#L370 


// least common multiple
size_t lcm(size_t a, size_t b) {
    size_t cur, div, next;

    cur = MAX2(a, b);
    div = MIN2(a, b);

    assert(div != 0, "lcm requires positive arguments");



But `os::large_page_size()` returns 0 instead of a default for the processor as before due to the new version of `scan_default_large_page_size()`.

This is my hunch from looking at the code. Still investigating and I will try setting a 64k page size in `os::vm_page_size()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From vkempik at openjdk.java.net  Fri May 14 15:29:35 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 14 May 2021 15:29:35 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>
Message-ID: <oKv9Wz6-knCjz8FQJHLyeFumLz9bNCegEr_KxPrN71A=.bf5500e6-f78c-4a29-8a14-0b4eb5f1a06a@github.com>

On Fri, 14 May 2021 14:50:13 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> let me check with macos/aarch64 on macos11.4b as it was giving problems with return address having pac signature sometimes too.
> 
> Nop, still crashes in SharedRuntime::raw_exception_handler_for_return_address with return address having pac signature in it (probably it's pac, not 100% sure), will investigate further

on macos11.4b it's getting something that looks like PAC-ed pointer in src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 487
  address generate_forward_exception() {
...
    __ mov(c_rarg1, lr);  <-- here
not sure how it got here bypassing all of your checks

maybe it's too early as 11.4 is still beta. ( beta3 ) and java_m1 is not arm64e process (arm64e = arm64 + PAC)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Fri May 14 15:39:47 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 14 May 2021 15:39:47 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <oKv9Wz6-knCjz8FQJHLyeFumLz9bNCegEr_KxPrN71A=.bf5500e6-f78c-4a29-8a14-0b4eb5f1a06a@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>
 <oKv9Wz6-knCjz8FQJHLyeFumLz9bNCegEr_KxPrN71A=.bf5500e6-f78c-4a29-8a14-0b4eb5f1a06a@github.com>
Message-ID: <Rw1PE2-qYQ8J4SojgJ0UKa1m71wxeAkelWaS54TJIGg=.6c788d70-2afe-4545-b72f-aa39002a9b16@github.com>

On Fri, 14 May 2021 15:26:24 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> let me check with macos/aarch64 on macos11.4b as it was giving problems with return address having pac signature sometimes too.
> 
> Nop, still crashes in SharedRuntime::raw_exception_handler_for_return_address with return address having pac signature in it (probably it's pac, not 100% sure), will investigate further

I suspect that 

> > let me check with macos/aarch64 on macos11.4b as it was giving problems with return address having pac signature sometimes too.
> > Nop, still crashes in SharedRuntime::raw_exception_handler_for_return_address with return address having pac signature in it (probably it's pac, not 100% sure), will investigate further
> 
> on macos11.4b it's getting something that looks like PAC-ed pointer in src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 487
> address generate_forward_exception() {
> ...
> __ mov(c_rarg1, lr); <-- here
> not sure how it got here bypassing all of your checks
> 
> maybe it's too early as 11.4 is still beta. ( beta3 ) and java_m1 is not arm64e process (arm64e = arm64 + PAC)

Apple's Arm64e also signs function pointers (unlike Linux, as it'd break the published AArch64 ABI). If it's only failing in the beta then maybe they are signing additional things. (I've not got access to that).

It might be worth copying the assert I added to the linux_aarch64 version of fetch_compiled_frame_from_context() into the os_bsd version. That might catch what your seeing earlier.   (Happy to add that to my patch too).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From ddong at openjdk.java.net  Fri May 14 16:00:09 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 14 May 2021 16:00:09 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  add missing include

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/b02705f0..e9c674ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3901.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901

PR: https://git.openjdk.java.net/jdk/pull/3901

From ddong at openjdk.java.net  Fri May 14 16:03:46 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 14 May 2021 16:03:46 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7]
In-Reply-To: <2iWHZyXol0hYutYUXe4KGOdq2sw2x-dn0iAhDzByfTo=.d855fc67-247c-4e2d-8861-fddb6bddf2bf@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <b2K9D0KPJhFyIlkdP2hxuNsC1F4P4b56_C0a7925gww=.b7a50ca2-1f96-434b-a9a1-d5709af1a5bb@github.com>
 <2iWHZyXol0hYutYUXe4KGOdq2sw2x-dn0iAhDzByfTo=.d855fc67-247c-4e2d-8861-fddb6bddf2bf@github.com>
Message-ID: <Hw7l9m4SgRiC5WrPfWVKZmDhle_5dH3tI_Cw_3mIfFs=.75a44eab-ee16-4079-b190-a5fc36698a00@github.com>

On Fri, 14 May 2021 12:31:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor
>
> src/hotspot/share/prims/resolvedMethodTable.cpp line 56:
> 
>> 54: 
>> 55: unsigned int method_hash(const Method* method) {
>> 56:   unsigned int hash = method->method_holder()->class_loader_data()->identity_hash();
> 
> I don't see "#include classfile/classLoaderData.hpp" in your patch. Did you verify it builds successfully? I saw a compilation failure without the include:
> 
> 
> src/hotspot/share/prims/resolvedMethodTable.cpp:56:67: error: member access into incomplete type 'ClassLoaderData'
>   unsigned int hash = method->method_holder()->class_loader_data()->identity_hash();
>                                                                   ^
> src/hotspot/share/memory/allocation.hpp:260:7: note: forward declaration of 'ClassLoaderData'
> class ClassLoaderData;
>       ^
> 1 error generated.

Sorry, I only verify it with normal build parameters, and I forgot that "precompiled.hpp" might be disabled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From vlivanov at openjdk.java.net  Fri May 14 16:22:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 14 May 2021 16:22:40 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
Message-ID: <1sqBTtizLtZ7z8OXiUPfDKT6dPmVh_jS7AGEF14s8sw=.2a69246d-58ca-4b11-942b-30e5223842fa@github.com>

On Fri, 14 May 2021 16:00:09 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing include

I'll submit the patch for testing and sponsor once it is over.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3901

From vkempik at openjdk.java.net  Fri May 14 16:54:37 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 14 May 2021 16:54:37 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <Rw1PE2-qYQ8J4SojgJ0UKa1m71wxeAkelWaS54TJIGg=.6c788d70-2afe-4545-b72f-aa39002a9b16@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>
 <oKv9Wz6-knCjz8FQJHLyeFumLz9bNCegEr_KxPrN71A=.bf5500e6-f78c-4a29-8a14-0b4eb5f1a06a@github.com>
 <Rw1PE2-qYQ8J4SojgJ0UKa1m71wxeAkelWaS54TJIGg=.6c788d70-2afe-4545-b72f-aa39002a9b16@github.com>
Message-ID: <GL5ZbNppEW13hrK7FTSLkbzfqeAJLlO0xodXX_B10_E=.d8d81a6b-694a-424a-988c-431afb69c709@github.com>

On Fri, 14 May 2021 15:37:13 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> It might be worth copying the assert I added to the linux_aarch64 version of fetch_compiled_frame_from_context() into the os_bsd version. That might catch what your seeing earlier. (Happy to add that to my patch too).

I have tried that and few more things, nothing catches that, only clearing upper 28 bits in c_rarg1 in generate_forward_exception helps. pauth_ptr_is_raw doesn't think it's pac-ed ptr ( maybe it always returns true on arm64 ( not arm64e))

here is example of ptrs on one run

return_address must be a return address: 0x9221800138009a5c
return_address must be a return address: 0x5c08800138009a5c
return_address must be a return address: 0x5c08800138009a5c
return_address must be a return address: 0x8713800138009a5c
return_address must be a return address: 0x0514800138009a5c
return_address must be a return address: 0x8d7a000138009a5c
return_address must be a return address: 0x403c000138009a5c
return_address must be a return address: 0x492d000138009a5c
return_address must be a return address: 0x403c000138009a5c

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From aph at openjdk.java.net  Fri May 14 16:54:37 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 14 May 2021 16:54:37 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <Q-Fq1dP9cDUj-0K_Q46uT8ZItKVIrIImBt2_10Q5qQU=.4c8b0a86-1664-4dcd-93ef-d418edaa42a4@github.com>

On Fri, 14 May 2021 11:22:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

src/hotspot/cpu/aarch64/pauth_aarch64.hpp line 44:

> 42: #else
> 43:   asm volatile ("mov x30, %0;"
> 44:                 XPACLRI

There's no need for this to be volatile.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From aph at openjdk.java.net  Fri May 14 16:57:41 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 14 May 2021 16:57:41 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <XGHsqiLcZ14LZd1xSaiBiQ4RpLeZOBHjxswvv3xVUWQ=.55946252-4092-459d-be2c-5a24839bff27@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <XGHsqiLcZ14LZd1xSaiBiQ4RpLeZOBHjxswvv3xVUWQ=.55946252-4092-459d-be2c-5a24839bff27@github.com>
Message-ID: <sKSrN2ZitlItEMB26100no38nopx5kBfkUvMI9T9Ku4=.20ae5562-4279-4cb3-a8f5-7e9cc5022139@github.com>

On Fri, 14 May 2021 13:19:59 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> Windows build is failing because it doesn't like volatile:
> d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\pauth_aarch64.hpp(43): error C2059: syntax error: 'volatile'
> 
> I guess the fix is to put pauth_aarch64.hpp into the os_arch/ directories. I wanted to avoid that because each copy would be almost identical. Unless anyone has any better ideas?

Sure, write a version in assembler and call it as extern "C".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From xliu at openjdk.java.net  Fri May 14 17:05:39 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 14 May 2021 17:05:39 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <2UmgvXanZYU0EVLZWhwJhSSX5pSBOdVOX3054Iom4Ag=.6f472dc9-0684-452a-90da-4f9277ab0367@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

hi, Reviewers,  
Ping?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From coleenp at openjdk.java.net  Fri May 14 17:12:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 14 May 2021 17:12:37 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
Message-ID: <dVnlfzQvSEFNZMK0W6hmgp-G7jT56G8E9PqQVsGJ0iU=.df491fd7-33f3-47eb-8685-f5005f6498f5@github.com>

On Thu, 29 Apr 2021 04:50:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.
> 
> Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in data holder structures which all are named "Metaspace" something and all do a very similar job. In particular, we have:
> 
> - MetaspaceSizesSnapshot (used for gc logs)
> - MetaspaceSnapshot (used in NMT)
> - MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
> - MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
> - CompressedKlassSpacePool and MetaspacePool (used for MXBeans)
> 
> As much as possible coding should be unified.
> 
> In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).
> 
> -----------------------
> 
> This patch introduces two new data holder structures:
> - `MetaspaceStats` holds reserved/committed/used counter
> - `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.
> 
> Furthermore, the patch introduces two new APIs in MetaspaceUtils:
> - `MetaspaceStats get_statistics(type)`
> - `MetaspaceCombinedStats get_combined_statistics()`
> The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.
> 
> The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:
> 
> - GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.
> 
> - NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
>    - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
>    - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
>    - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).
> 
> - jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
> 	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
> 	- I simplified the counter coding a lot. I think the complexity was not needed.
> 	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.
> 
> - `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 
> 
> - JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
> 	- I completely removed `MetaspaceSizes`
> 	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`
> 
> - MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.
> 
> - Added a simple gtest for the new APIs
> 
> Tests: 
> - manually executed hotspot tier1 tests
> - explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
> - SAP tests ran for several weeks on all our platforms

This looks good to me.  Nice cleanup removing duplicated metaspace counting code!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3786

From stuefe at openjdk.java.net  Fri May 14 18:10:39 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 14 May 2021 18:10:39 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <dVnlfzQvSEFNZMK0W6hmgp-G7jT56G8E9PqQVsGJ0iU=.df491fd7-33f3-47eb-8685-f5005f6498f5@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
 <dVnlfzQvSEFNZMK0W6hmgp-G7jT56G8E9PqQVsGJ0iU=.df491fd7-33f3-47eb-8685-f5005f6498f5@github.com>
Message-ID: <EyXQlWRjgsEG7AfBopvUrLDTdGALYczy8Rr2jMVo8C4=.4b053093-3d04-46ed-89e5-bf44a1389bfb@github.com>

On Fri, 14 May 2021 17:09:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good to me. Nice cleanup removing duplicated metaspace counting code!

Thank you Coleen!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3786

From kbarrett at openjdk.java.net  Fri May 14 18:21:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:21:40 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods [v2]
In-Reply-To: <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
 <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>
Message-ID: <-25vOhGyYsdfn2Xe1stPB_ibzKAvDawe-ZKMGhomA68=.8572786e-ef17-4635-97bb-4732b1d7ac9c@github.com>

On Tue, 11 May 2021 10:48:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Adding the assertion, and fixing a benign violation.
>> 
>> Test: tier1-7; no violation of this assertion.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge master
>  - delta

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3900

From ayang at openjdk.java.net  Fri May 14 18:21:41 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 May 2021 18:21:41 GMT
Subject: RFR: 8260046: Assert left >= right in pointer_delta() methods [v2]
In-Reply-To: <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
 <1aTYA16GSEDNFCCIEjfxAo3U902d_4s1VAbjwsXM1Jo=.321ebe26-9d71-4a60-bdda-84851df794eb@github.com>
Message-ID: <i40aS6KxLsZEIcHJjQsovhFL0dJioSQXjYuOMEJTvE8=.34fbcf88-8ab0-4852-afb9-315cb821bbcc@github.com>

On Tue, 11 May 2021 10:48:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Adding the assertion, and fixing a benign violation.
>> 
>> Test: tier1-7; no violation of this assertion.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge master
>  - delta

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3900

From ayang at openjdk.java.net  Fri May 14 18:21:41 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 May 2021 18:21:41 GMT
Subject: Integrated: 8260046: Assert left >= right in pointer_delta() methods
In-Reply-To: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
References: <1Wry4HoWqk8nLQXjYWwGooj1MCtE6BVwvUyrH3nTKnA=.c00fb6c6-23c4-4f09-8bd1-f5b5c3d7ebc6@github.com>
Message-ID: <lv3ZpmMDCZrnxKDMfvzjhilNClDpT-lBm8kSD_Q7fls=.80ac8a59-e95e-4d6b-b934-7413fb8c8a43@github.com>

On Thu, 6 May 2021 14:02:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Adding the assertion, and fixing a benign violation.
> 
> Test: tier1-7; no violation of this assertion.

This pull request has now been integrated.

Changeset: 360928d1
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/360928d16dbfd2e878694995a2f65ba5b5a1dbe6
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8260046: Assert left >= right in pointer_delta() methods

Reviewed-by: sjohanss, kbarrett, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/3900

From sviswanathan at openjdk.java.net  Fri May 14 18:37:25 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 14 May 2021 18:37:25 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
Message-ID: <9xgNS8A7za3iluvvsT_7BTrGCncCWQfXnP8pE-yATE4=.4f453320-d8b4-43f8-92e9-455ea97cbe23@github.com>

On Fri, 7 May 2021 16:42:30 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @run case

@vnkozlov Could you please review and approve this PR if it looks ok to you?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From kbarrett at openjdk.java.net  Fri May 14 18:42:06 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:42:06 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v5]
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <0Zvd_LtOrgN-vGEPtCbd-q3RG97ZTgGRr1mRlowBpxw=.7744f9eb-0ec7-4192-b21d-8af96ee8e79f@github.com>

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into new_dedup2
 - fix shenandoah merge
 - Merge branch 'master' into new_dedup2
 - misc cleanups
 - refactor Requests::add
 - fix typo
 - more comment improvements
 - improve naming and comments around injected String flags
 - fix some typos in comments
 - New string deduplication

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=04
  Stats: 6192 lines in 105 files changed: 2369 ins; 3204 del; 619 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Fri May 14 18:42:08 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:42:08 GMT
Subject: Integrated: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <WSFG03c-7TDcs-Qifa-dv8v9i-yaKk04ZnuLKiUMYuA=.4e717003-a4fd-4b3d-9754-48373fe56edb@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

This pull request has now been integrated.

Changeset: be0a6552
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be0a655208f64e076e9e0141fe5dadc862cba981
Stats:     6192 lines in 105 files changed: 2369 ins; 3204 del; 619 mod

8254598: StringDedupTable should use OopStorage

Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Co-authored-by: Zhengyu Gu <zgu at openjdk.org>
Reviewed-by: coleenp, iklam, tschatzl, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Fri May 14 18:42:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:42:07 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v5]
In-Reply-To: <OfLLYd80v7U4EzIJczqUk5mJcToR9gvf_w841_ucBVU=.6d88d61e-3c5e-4ad7-85e6-b5607de01efb@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <IhganH3OvJTx-vLN0t3WBTpisPsFuj8qrueA9d3C31A=.2bee0cf4-8e7a-4a1d-a0e3-9cb09665d2c3@github.com>
 <OfLLYd80v7U4EzIJczqUk5mJcToR9gvf_w841_ucBVU=.6d88d61e-3c5e-4ad7-85e6-b5607de01efb@github.com>
Message-ID: <g5EIbUFcauKGQI44xn01J4R-75PT0I9odB540uMeaDI=.d97807f3-45a0-41d3-b348-f878667e0039@github.com>

On Fri, 14 May 2021 12:40:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into new_dedup2
>>  - fix shenandoah merge
>>  - Merge branch 'master' into new_dedup2
>>  - misc cleanups
>>  - refactor Requests::add
>>  - fix typo
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>>  - New string deduplication
>
>> The "merge from master" commit ([ccb9951](https://github.com/openjdk/jdk/commit/ccb99515d020785d7fe1cf9a1c247aeed775dc19)) doesn't build with Shenandoah. I've asked Zhengyu to take a look.
> 
> Just missing a parameter:
> 
> ```diff --git a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
> index ddaa66ccc14..93a067fa22d 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
> @@ -57,7 +57,7 @@ ShenandoahInitMarkRootsClosure::ShenandoahInitMarkRootsClosure(ShenandoahObjToSc
>  
>  template <class T>
>  void ShenandoahInitMarkRootsClosure::do_oop_work(T* p) {
> -  ShenandoahMark::mark_through_ref<T, NO_DEDUP>(p, _queue, _mark_context, false);
> +  ShenandoahMark::mark_through_ref<T, NO_DEDUP>(p, _queue, _mark_context, NULL, false);
>  }```

Thanks @zhengyu123 for the shenandoah merge fix.

Thanks @iklam , @coleenp , @tschatzl , @albertnetymk for reviews.

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:
> 
>> 312:   size_t _bucket_index;
>> 313:   size_t _shrink_index;
>> 314:   bool _grow_only;
> 
> Indentation

Not sure what this indentation comment is referring to.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From manc at openjdk.java.net  Fri May 14 19:31:40 2021
From: manc at openjdk.java.net (Man Cao)
Date: Fri, 14 May 2021 19:31:40 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
Message-ID: <YzC2xchoA-g3GTyhrBUIIAM5VuS22Dww8B8x7-jVO6c=.069e0afd-b6fd-4e40-9ac6-b09a6fdfe86b@github.com>

On Thu, 13 May 2021 02:05:30 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
> 
> -Man

Hi David,

By "remote" I mean any thread that is not the current running thread itself. Basically "remote" = "non-self". In the handhshake model's terminology, remote executable means "executing thread" != "target thread". Remote is commonly used as a synonym for "non-local" in literature about CPU and NUMA, e.g. "remote cache", "remote memory".

Do you prefer the old term "non_self_executable" over "remote_executable"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From kvn at openjdk.java.net  Fri May 14 20:20:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 14 May 2021 20:20:38 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
Message-ID: <6U5EDcQli0NUlrhdOBtzkujogfwN_39V3bPs_7oIUX0=.e51f26d8-b503-4680-8d6e-34311a1b300f@github.com>

On Fri, 7 May 2021 16:42:30 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @run case

Ping @pfustc about permission to add his JMH micro or write your own based on examples in `test/micro/org/openjdk/bench/java/util/`

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6799:

> 6797:     }
> 6798: 
> 6799:     if (VM_Version::supports_avx2() && UseAdler32Intrinsics) {

Based on code in `vm_version_x86.cpp` `UseAdler32Intrinsics` is `true` only with `avx2`. So you don't need to check it here.

src/hotspot/cpu/x86/vm_version_x86.cpp line 902:

> 900: 
> 901: #ifdef _LP64
> 902:   if (supports_avx2() && UseAdler32Intrinsics) {

Check is incorrect. Should check only `if (supports_avx2()) `

test/hotspot/jtreg/compiler/intrinsics/zip/TestAdler32.java line 32:

> 30:  *
> 31:  * @run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestAdler32 -m
> 32:  * @run main/othervm/timeout=600 -XX:+UnlockDiagnosticVMOptions -XX:+UseAdler32Intrinsics compiler.intrinsics.zip.TestAdler32 -m

Enabling intrinsic unconditionally is incorrect - test will fail (gives waring) on machines which do not support avx2.
Do not modify this tests. To test improvement JMH benchmark should be used.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Fri May 14 21:47:32 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Fri, 14 May 2021 21:47:32 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v8]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <62je7XSswP2cqpraFbnxN65flI6m5fGA0as9JVsYbAY=.df9d3002-98d3-4093-aa29-b7f37b1bbab5@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> For the following benchmark:
> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> 
> The optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  removed checkings for UseAdler32Intrinsics

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/3851c602..7290944b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=06-07

  Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Fri May 14 22:57:00 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Fri, 14 May 2021 22:57:00 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v8]
In-Reply-To: <62je7XSswP2cqpraFbnxN65flI6m5fGA0as9JVsYbAY=.df9d3002-98d3-4093-aa29-b7f37b1bbab5@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <62je7XSswP2cqpraFbnxN65flI6m5fGA0as9JVsYbAY=.df9d3002-98d3-4093-aa29-b7f37b1bbab5@github.com>
Message-ID: <ulgTpsxiDiHbWLXP1PUphHeeIr2jrPJPv5FpwFp4Zzs=.2c80ce79-23d0-41db-a012-bb98a5ff8baf@github.com>

On Fri, 14 May 2021 21:47:32 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed checkings for UseAdler32Intrinsics

@pfustc Hi Pengfei,
I implemented Adler32 intrinsic for x86. Can I add your JMH micro http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java into openjdk test/micro/org/openjdk/bench/java/util/?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From jiefu at openjdk.java.net  Fri May 14 23:18:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 14 May 2021 23:18:53 GMT
Subject: RFR: 8267153: Problemlist
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise
 from CI
In-Reply-To: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
References: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
Message-ID: <FnSacgHuv3W5KefSxD-wVvxjF1vcgeEGDBdLAk4W8cY=.e6ef993e-57fe-4c05-8321-9b23ee7fd85b@github.com>

On Fri, 14 May 2021 12:20:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
>   can I have reviews for this small change that problemlists jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove noise from the CI.
> 
> Thanks,
>   Thomas

Marked as reviewed by jiefu (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4031

From sviswanathan at openjdk.java.net  Sat May 15 01:48:35 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 15 May 2021 01:48:35 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v3]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <2gAn7RV3gzdAOuAZNRcINNLi4NKBwYJW-4NdjcRgpCE=.5e3c0cc3-c89b-486d-8749-cfa630e59f04@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master
 - Merge master
 - remove whitespace
 - Merge master
 - Small fix
 - cleanup
 - x86 short vector math optimization for Vector API

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=02
  Stats: 417101 lines in 120 files changed: 416935 ins; 123 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Sat May 15 02:06:29 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 15 May 2021 02:06:29 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v4]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <eeemp-eAcjaVzum-WqR0XntK1GWJW51LUcZAmPVyK0k=.ce78c7c4-2efa-42de-86da-050be949f05c@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Add missing Lib.gmk

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/6e105f51..01a549e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=02-03

  Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From tschatzl at openjdk.java.net  Sat May 15 09:49:41 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Sat, 15 May 2021 09:49:41 GMT
Subject: Integrated: 8267153: Problemlist
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise
 from CI
In-Reply-To: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
References: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
Message-ID: <FUzPKez5M33liqhtzPM_HnKEwTv_C6of04y_O0Ivitk=.ead7eec4-0718-4c9d-9f98-a644e1dd48c9@github.com>

On Fri, 14 May 2021 12:20:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
>   can I have reviews for this small change that problemlists jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove noise from the CI.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 10cafd24
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/10cafd244db8eebddc81fa312d9358ab62566cc1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8267153: Problemlist jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise from CI

Reviewed-by: dcubed, jiefu

-------------

PR: https://git.openjdk.java.net/jdk/pull/4031

From xliu at openjdk.java.net  Sun May 16 17:40:46 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 16 May 2021 17:40:46 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v15]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <PlKRvZEr5tMIksHuq8ls92Lyluv5Wsx9dQoSfQ2hSXw=.6d729db1-a0b4-4bca-bb40-4f65a20f00e0@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with three additional commits since the last revision:

 - refactor code and update per reviewers' feedback.
   
   1. change classname from logAsyncFlusher to logAsyncWriter.
   2. completely remove Terminate(), which is not safe.
   3. refactor Initialize() and ensure it can handle concurrent synchronuous logging writers.
   4. refactor gtest. make sure the 1st parameter of EXPECT/ASSERT is the epxected value.
   5. add a GTestWrapper in jtreg, which ran the gtest in async mode.
 - Replace Mutex with Semaphore.
   
   Use 2 sempahores to replace the Monitor*.
   Monitor in hotspot is combination of pthread_mutex_t and pthread_cond_t.
   _lock has the initial value 1. it acts as a 'mutex'.
   _sem has the initial value 0, which denotes how many messages have enqueued.
 - Refactor Initialize() and Termiante().
   
   Define they are 2 synchronization points. async logging exclusively takes
   over from synchronous logging between 2 points.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/7df8b1ed..e19e90a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=13-14

  Stats: 926 lines in 15 files changed: 400 ins; 452 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sun May 16 18:00:52 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 16 May 2021 18:00:52 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
Message-ID: <pXdON2YI3WHz2-rq0A2M-0RN2XGWbVlZy8wmEB0JgtY=.c70ace9d-cc3f-4106-80ae-6a2c086098a0@github.com>

On Thu, 13 May 2021 06:55:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
>> > About synchronization: I don't understand the reasoning behind having a periodic flush. Would an implementation which just flushes if output is available not be less complex and actually better? Why make the flusher thread wake up twice a second if there is nothing to do? OTOH why wait 500ms if there is actually output to be printed?
>> 
>> From my observation, the character of logging events is high-frequent but low cost. Using HotSpot Monitor(the combination of pthead_mutex_t and pthread_cond_t) for an individual logging event is expensive. The cost of waking up AsyncLog thread and lock/unlock data structure would easily shadow IO jobs(fprintf), which usually are cached in libc.
>> 
>> My strategy is to do IO jobs in batch and amortize the cost of synchronizations. In my design, m.wait() in the following code snippet wakes up mainly due to the load of buffer is over 3/4.
>> 
>> ```c++
>>   while (_state == ThreadState::Running) {
>>     {
>>       MonitorLocker m(&_lock, Mutex::_no_safepoint_check_flag);
>>       m.wait(500 /* ms, timeout*/);
>>     }
>>     flush();
>>   }
>> ```
>> 
>> 500ms here, which was the global option `LogAsyncInterval` , serves as a **stall protector**. If Hotspot stalls for whatever reasons, AsyncLog thread still can flush messages after timeout. I think it's useful for develops who may rely on the log files to figure out what happened inside of the hanging hotspot. Without timeout parameter, AsyncLog Thread may leave messages in the buffer and never get a change to flush them if all threads stall.
> 
> Okay, I understand.

hi, @tstuefe & @dholmes-ora , 

I replace Monitor with Semaphore.  Previously, the monitor _lock served in twofold meaning. 
1. mutex to protect key data structure. 
2. condition_variable to signal AsyncLog Thread to wake up. 

In this revision, I replace '_lock' with two separated semaphores.  Semaphore is primitive and don't reply on Hotspot Runtime, so I can remove some workarounds of Hotspot mutex. 

Not only it can simplify implementation, it is also faster than Monitor.  I guess it's still because it's more primitive than pthread.  eg. _sem->notify() just increases an integer in atomic and signal. Monitor needs unlock, signal, lock. 

Baseline is all=trace by default. 
`perf stat -r 300  ./build/linux-x86_64-server-release/images/jdk/bin/java  -Xlog:'all=trace:file=hotspot-gold.log:uptime,tid,l,tg:filecount=0' --version > /dev/null`

Monitor and Semaphore  are both synchronous logging with different implementation. 
`perf stat -r 300  ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:async -Xlog:'all=trace:file=hotspot-async.log:uptime,tid,l,tg:filecount=0' --version > /dev/null`



Baseline:           0.102001 +- 0.000162 seconds time elapsed  ( +-  0.16% )
Monitor:            0.078309 +- 0.000161 seconds time elapsed  ( +-  0.21% )
Sempahore:          0.068590 +- 0.000137 seconds time elapsed  ( +-  0.20% )

 
I compared the outputs files. The semaphore-based revision also output all logs like synchronous one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From pli at openjdk.java.net  Mon May 17 03:54:47 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 17 May 2021 03:54:47 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v8]
In-Reply-To: <ulgTpsxiDiHbWLXP1PUphHeeIr2jrPJPv5FpwFp4Zzs=.2c80ce79-23d0-41db-a012-bb98a5ff8baf@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <62je7XSswP2cqpraFbnxN65flI6m5fGA0as9JVsYbAY=.df9d3002-98d3-4093-aa29-b7f37b1bbab5@github.com>
 <ulgTpsxiDiHbWLXP1PUphHeeIr2jrPJPv5FpwFp4Zzs=.2c80ce79-23d0-41db-a012-bb98a5ff8baf@github.com>
Message-ID: <7heFf4AJDvsDLlBqyQ-c7PiH2R0tbxp2eqYg0iz1GX4=.2b64476f-60e6-40b5-bd41-a2aeb121f9e3@github.com>

On Fri, 14 May 2021 22:53:30 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

> @pfustc Hi Pengfei,
> I implemented Adler32 intrinsic for x86. Can I add your JMH micro http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java into openjdk test/micro/org/openjdk/bench/java/util/?

Sorry I missed your previous mention.

That jmh case was written by me. I didn't add any copyright header in the source file. So I think anyone can use it or contribute it to the jdk source for free.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From dholmes at openjdk.java.net  Mon May 17 04:07:44 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 04:07:44 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v4]
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <Z9zBbwDOMlO2tfJnmcwKfELlNz7mj3m1Kt-OLLHfvfo=.c99111cf-bb28-4d45-8067-7766efd623a0@github.com>

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8252685-JavaThread
 - Update after merge with master
 - Merge branch 'master' into 8252685-JavaThread
 - Review feedback from Serguei
 - Merge
 - 8252685: APIs that require JavaThread should take JavaThread arguments

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=03
  Stats: 535 lines in 120 files changed: 14 ins; 28 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877

PR: https://git.openjdk.java.net/jdk/pull/3877

From dholmes at openjdk.java.net  Mon May 17 04:08:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 04:08:28 GMT
Subject: Integrated: 8252685: APIs that require JavaThread should take
 JavaThread arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <U9jEpgB76_M4HyJQ8-X6vB5VW6o3qQUbWC6CWqEOPkw=.03842586-29ff-4780-af83-6e56f4a58888@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 02f895c5
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02f895c5f6f6de38549337d45ed8ba4c446e9677
Stats:     535 lines in 120 files changed: 14 ins; 28 del; 493 mod

8252685: APIs that require JavaThread should take JavaThread arguments

Reviewed-by: coleenp, sspitsyn, kvn, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/3877

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 05:47:39 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 05:47:39 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v9]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> For the following benchmark:
> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> 
> The optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Add jmh test for Adler32

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/7290944b..c8e2ab05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=07-08

  Stats: 62 lines in 1 file changed: 62 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806

PR: https://git.openjdk.java.net/jdk/pull/3806

From jiefu at openjdk.java.net  Mon May 17 06:11:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 17 May 2021 06:11:07 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow
Message-ID: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>

Hi all,

This is a follow-up of JDK-8260046.
And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
Let's fix it

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8267213: assert(left >= right) failed: avoid underflow

Changes: https://git.openjdk.java.net/jdk/pull/4044/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267213
  Stats: 21 lines in 3 files changed: 15 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4044.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4044/head:pull/4044

PR: https://git.openjdk.java.net/jdk/pull/4044

From david.holmes at oracle.com  Mon May 17 06:28:26 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 17 May 2021 16:28:26 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <YzC2xchoA-g3GTyhrBUIIAM5VuS22Dww8B8x7-jVO6c=.069e0afd-b6fd-4e40-9ac6-b09a6fdfe86b@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <YzC2xchoA-g3GTyhrBUIIAM5VuS22Dww8B8x7-jVO6c=.069e0afd-b6fd-4e40-9ac6-b09a6fdfe86b@github.com>
Message-ID: <3175d62a-32d0-633f-5161-bde0b6b9d7fd@oracle.com>

On 15/05/2021 5:31 am, Man Cao wrote:
> On Thu, 13 May 2021 02:05:30 GMT, Man Cao <manc at openjdk.org> wrote:
> 
>> Hi all,
>>
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>>
>> -Man
> 
> Hi David,
> 
> By "remote" I mean any thread that is not the current running thread itself. Basically "remote" = "non-self". In the handhshake model's terminology, remote executable means "executing thread" != "target thread". Remote is commonly used as a synonym for "non-local" in literature about CPU and NUMA, e.g. "remote cache", "remote memory".
> 
> Do you prefer the old term "non_self_executable" over "remote_executable"?

Yes, because we are dealing with self or non-self. I don't think 
referring to self/current as "local" is appropriate terminology here, 
and so remote also does not fit IMO.

But I'm also confused about the general model here. To me async means 
the requestor does not wait for the operation to complete, so the 
requestor can never execute the operation here. That leaves only the 
target (which is what we currently have) or a third thread, which at the 
moment (ignoring sync/async aspect) only the VMThread is allowed because 
the operation happens at a safepoint. Are you looking to generalize this 
to allow an arbitrary third thread to execute the operation? If so I 
don't understand the model as it seems to me that what you are 
effectively asking for is a way to "suspend" a target thread until some 
arbitrary action is performed by another thread, but that thread can't 
initiate a handshake directly, so that responsibility falls to yet 
another thread.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From dholmes at openjdk.java.net  Mon May 17 06:36:44 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 06:36:44 GMT
Subject: RFR: 8267153: Problemlist
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise
 from CI
In-Reply-To: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
References: <kR0KQO088U5AdMEjNtmxqEawUL1djFXopQ9jUyKNkNw=.7d8229ce-d836-41e2-976d-ea4090de13e1@github.com>
Message-ID: <1L57Pp8omDHz3SROJ7-QtceYuzE2V9Hms7qsMVtSsw4=.c38d7fe7-7eb7-4525-a3b2-d947f4045b51@github.com>

On Fri, 14 May 2021 12:20:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
>   can I have reviews for this small change that problemlists jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove noise from the CI.
> 
> Thanks,
>   Thomas

JDK-8267218 is also now filed against this test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4031

From dholmes at openjdk.java.net  Mon May 17 06:48:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 06:48:39 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow
In-Reply-To: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
Message-ID: <c7U-QejDhMU8zQYj7MFGwxlqA5wJPu43BLsJi9B61ps=.9c9eb8b4-d44c-4c9d-a399-cc77960fa46d@github.com>

On Mon, 17 May 2021 03:56:22 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> This is a follow-up of JDK-8260046.
> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
> Let's fix it
> 
> Thanks.
> Best regards,
> Jie

Hi Jie,

I'm not sure this is the right fix. It seems to me from the comments about having a sane addr and pc that the basic assumption/premise is that addr > pc as it is being checked when expected to be part of the current instruction. So if addr < pc I would think pc_is_near_addr should be false.

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From xliu at openjdk.java.net  Mon May 17 07:12:51 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 17 May 2021 07:12:51 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
Message-ID: <1tCXq8p6OjdCuI_PiT57a6msUCsDIneRt_2c4b3v8kw=.92f5f78e-a5a2-4954-9c12-e34ea4106d9b@github.com>

On Thu, 13 May 2021 06:52:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 142:
> 
>> 140:     _buffer.pop_all(&logs);
>> 141:     AsyncLogMapIterator iter;
>> 142:     _stats.iterate(&iter);
> 
> All this is really difficult to understand for the casual reader. Clearer naming would help:
> - something like "move-list-content" instead of pop_all
> - the whole point of this iteration thing is to print the dropped counters, right? A function "Print Drop Counters" would be clearer. Unless you go the one-async-buffer-per-logfileoutput-route I mentioned earlier.

I will send out a patch to fix this along with the new discard policy. 
There's another issue.  `_stats.iterate(&iter)` here invokes `output->write_blocking` while holding lock!
This has compromised non-blocking protocol.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From sjohanss at openjdk.java.net  Mon May 17 07:37:20 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 17 May 2021 07:37:20 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
Message-ID: <ctI37ne4X5AzZ7s53Uc8PPLV-LDP7_qBnosYwxnI2fs=.f0d7e66a-1235-4230-b260-77cd596c3f31@github.com>

On Wed, 12 May 2021 22:47:15 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse flags & p vars, fix enclose
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Some additional comments. The update to `globals.hpp`stated in the CSR should also be included in this change:

diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp
index cfe5fd8116c..2d09075fb48 100644
--- a/src/hotspot/share/runtime/globals.hpp
+++ b/src/hotspot/share/runtime/globals.hpp
@@ -239,7 +239,8 @@ const intx ObjectAlignmentInBytes = 8;
           "Use intrinsics for java.util.Base64")                            \
                                                                             \
   product(size_t, LargePageSizeInBytes, 0,                                  \
-          "Large page size (0 to let VM choose the page size)")             \
+          "Maximum large page size used (0 will use the default large "     \
+          "page size for the environment as the maximum)")                  \
           range(0, max_uintx)                                               \
                                                                             \
   product(size_t, LargePageHeapSizeThreshold, 128*M,                        \

src/hotspot/os/linux/os_linux.cpp line 3512:

> 3510:   } else {
> 3511:       log_info(pagesize)("Large page size (" SIZE_FORMAT "%s) failed sanity check "
> 3512:                          "checking if smaller large page sizes are usable",

Please add a comma. 
Suggestion:

      log_info(pagesize)("Large page size (" SIZE_FORMAT "%s) failed sanity check, "
                         "checking if smaller large page sizes are usable",

src/hotspot/os/linux/os_linux.cpp line 3798:

> 3796:     _page_sizes.print_on(&ls);
> 3797:     ls.print("All large Page sizes: ");
> 3798:     all_large_pages.print_on(&ls);

I would prefer having those on separate lines and I also think the "all" part should be moved to the scanning function and be on `debug` level. The complete output would then be something like:

[0.001s][debug][pagesize] Large page sizes: 2M, 1G
[0.001s][info ][pagesize] Using the default large page size: 2M
[0.001s][info ][pagesize] Usable page sizes: 4k, 2M

-------------

Changes requested by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1153

From sjohanss at openjdk.java.net  Mon May 17 07:37:24 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 17 May 2021 07:37:24 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <2y0nRYYqBU11BNiLaMjNEsMA9QLloTmMZtacklo0jCk=.9a6799d6-cef8-4278-aef7-aa15cd95e3db@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
 <2y0nRYYqBU11BNiLaMjNEsMA9QLloTmMZtacklo0jCk=.9a6799d6-cef8-4278-aef7-aa15cd95e3db@github.com>
Message-ID: <I2KpGDB4QfKJqVEnPsb__CgXasCjRcN5C5ZQkZoWifs=.6f309a29-8144-4ed4-891c-9ce9bd0c7688@github.com>

On Wed, 12 May 2021 22:49:01 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reuse flags & p vars, fix enclose
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/os/linux/os_linux.cpp line 3528:
> 
>> 3526:           return true;
>> 3527:         }
>> 3528:       }
> 
> @kstefanj were you thinking of something more like this?

Yes, something like this. I might propose a follow up to change this slightly, but I first need to think about how we really should handle this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From jiefu at openjdk.java.net  Mon May 17 07:52:14 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 17 May 2021 07:52:14 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
Message-ID: <fGrrGpupqgKSPkNgNTTF0csTYJ1rW_5ywfjD7WnsSQA=.c3fc8297-e7dc-4d95-978c-43422df25f76@github.com>

> Hi all,
> 
> This is a follow-up of JDK-8260046.
> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
> Let's fix it
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Set false if addr < pc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4044/files
  - new: https://git.openjdk.java.net/jdk/pull/4044/files/9654893d..426480c9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4044.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4044/head:pull/4044

PR: https://git.openjdk.java.net/jdk/pull/4044

From jiefu at openjdk.java.net  Mon May 17 07:54:47 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 17 May 2021 07:54:47 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <c7U-QejDhMU8zQYj7MFGwxlqA5wJPu43BLsJi9B61ps=.9c9eb8b4-d44c-4c9d-a399-cc77960fa46d@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <c7U-QejDhMU8zQYj7MFGwxlqA5wJPu43BLsJi9B61ps=.9c9eb8b4-d44c-4c9d-a399-cc77960fa46d@github.com>
Message-ID: <tVsxY7A01RI68rqZMu8KvZkIvNyAhOlxnEQHe0TD3pI=.442d8769-50af-4be7-a6eb-4aa9d7f7343c@github.com>

On Mon, 17 May 2021 06:45:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Jie,
> 
> I'm not sure this is the right fix. It seems to me from the comments about having a sane addr and pc that the basic assumption/premise is that addr > pc as it is being checked when expected to be part of the current instruction. So if addr < pc I would think pc_is_near_addr should be false.
> 
> David

Thanks @dholmes-ora for your review.

Okay, I think your suggestion is good since it just works as before and won't make things worse.

But I'm not sure whether the basic assumption/premise that `addr > pc` is always right.

Let's consider the following case

...
    inst1
    inst2
    jmp L1  <--- sizeof(jmp) = 5 bytes, the first byte is on Page k, the other 4 bytes on Page k+1
    ...
L1:

In this case, I think `addr` would point to some part of the jmp instruction and `pc` would point to L1, which means addr < pc. 
What do you think?

Thanks.
Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From rehn at openjdk.java.net  Mon May 17 08:33:58 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 08:33:58 GMT
Subject: RFR: 8266637: CHT: Add insert_and_get method
In-Reply-To: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
References: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
Message-ID: <T9oW2bgKOcDEbCpAgMt6Ahhy35OpDxOUCu9Tyg6NYtk=.a41057bd-67c3-42ad-853b-deae5428794b@github.com>

On Fri, 7 May 2021 09:27:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to add an `insert_get` method to the CHT.  The method combines `insert()` and `get()` methods to decrease the amount of global synchronization needed for `get()` calls after an `insert` call. 
> 
> Testing: tier1-3

Thanks, looks good!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3915

From iwalulya at openjdk.java.net  Mon May 17 08:33:58 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 17 May 2021 08:33:58 GMT
Subject: RFR: 8266637: CHT: Add insert_and_get method
In-Reply-To: <T9oW2bgKOcDEbCpAgMt6Ahhy35OpDxOUCu9Tyg6NYtk=.a41057bd-67c3-42ad-853b-deae5428794b@github.com>
References: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
 <T9oW2bgKOcDEbCpAgMt6Ahhy35OpDxOUCu9Tyg6NYtk=.a41057bd-67c3-42ad-853b-deae5428794b@github.com>
Message-ID: <iaNcLAcmfGcqz0oMLqUAehJiSK90Kf0p2EnnIho_Dnc=.fd090183-829c-4bd6-9dd1-866f0950dd27@github.com>

On Mon, 17 May 2021 08:28:50 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to add an `insert_get` method to the CHT.  The method combines `insert()` and `get()` methods to decrease the amount of global synchronization needed for `get()` calls after an `insert` call. 
>> 
>> Testing: tier1-3
>
> Thanks, looks good!

Thanks @robehn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3915

From ayang at openjdk.java.net  Mon May 17 09:24:39 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 May 2021 09:24:39 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <fGrrGpupqgKSPkNgNTTF0csTYJ1rW_5ywfjD7WnsSQA=.c3fc8297-e7dc-4d95-978c-43422df25f76@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <fGrrGpupqgKSPkNgNTTF0csTYJ1rW_5ywfjD7WnsSQA=.c3fc8297-e7dc-4d95-978c-43422df25f76@github.com>
Message-ID: <_b1tNX5u-09ef07fWWPWYRsE_9vSiqA-6CkGYCCSr34=.6e1095ac-e66c-4fad-9c77-a39c5e452bc7@github.com>

On Mon, 17 May 2021 07:52:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> This is a follow-up of JDK-8260046.
>> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
>> Let's fix it
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set false if addr < pc

How about removing the `if`?


bool pc_is_near_addr = (addr >= pc) && 
                       pointer_delta((void*) addr, (void*) pc, sizeof(char)) < 15;

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From jiefu at openjdk.java.net  Mon May 17 09:39:18 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 17 May 2021 09:39:18 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v3]
In-Reply-To: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
Message-ID: <rXnW92dGIxYAJ3xyeWc5rQabPL7txtDnFN3WNxUj9n8=.fbe1a03c-cb10-4cec-9eee-228f9b310dad@github.com>

> Hi all,
> 
> This is a follow-up of JDK-8260046.
> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
> Let's fix it
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Remove if

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4044/files
  - new: https://git.openjdk.java.net/jdk/pull/4044/files/426480c9..812f3c5a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=01-02

  Stats: 15 lines in 3 files changed: 0 ins; 9 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4044.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4044/head:pull/4044

PR: https://git.openjdk.java.net/jdk/pull/4044

From jiefu at openjdk.java.net  Mon May 17 09:39:18 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 17 May 2021 09:39:18 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <_b1tNX5u-09ef07fWWPWYRsE_9vSiqA-6CkGYCCSr34=.6e1095ac-e66c-4fad-9c77-a39c5e452bc7@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <fGrrGpupqgKSPkNgNTTF0csTYJ1rW_5ywfjD7WnsSQA=.c3fc8297-e7dc-4d95-978c-43422df25f76@github.com>
 <_b1tNX5u-09ef07fWWPWYRsE_9vSiqA-6CkGYCCSr34=.6e1095ac-e66c-4fad-9c77-a39c5e452bc7@github.com>
Message-ID: <Go3prrneErZVRBInR2tOnqKrVCRD0hYegYbCJQQMeDA=.df7d2734-1271-417c-a594-d0ee2c0ba55f@github.com>

On Mon, 17 May 2021 09:21:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> How about removing the `if`?
> 
> ```
> bool pc_is_near_addr = (addr >= pc) && 
>                        pointer_delta((void*) addr, (void*) pc, sizeof(char)) < 15;
> ```

Good suggestion.
Updated.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From iwalulya at openjdk.java.net  Mon May 17 09:44:44 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 17 May 2021 09:44:44 GMT
Subject: Integrated: 8266637: CHT: Add insert_and_get method
In-Reply-To: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
References: <-UWnpcKxpblIK0Ol9nmlEIvcxYUWA7IzZzAYE-vY11c=.9bfafc9c-1d4f-4368-bf90-480d3c9ce115@github.com>
Message-ID: <UZSHDz9HmcvFmQmGW6HOprpvxlcMqE1a9wBBHyBklsk=.4813104e-27cc-498d-a460-fde199a18d9e@github.com>

On Fri, 7 May 2021 09:27:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to add an `insert_get` method to the CHT.  The method combines `insert()` and `get()` methods to decrease the amount of global synchronization needed for `get()` calls after an `insert` call. 
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: 2313a218
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2313a2187a949dd0c101b8f8fb5ffc31089d6817
Stats:     38 lines in 3 files changed: 30 ins; 0 del; 8 mod

8266637: CHT: Add insert_and_get method

Reviewed-by: tschatzl, rehn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3915

From akozlov at openjdk.java.net  Mon May 17 10:47:07 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 17 May 2021 10:47:07 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <05d6bc80-f34d-c128-33af-f5299ac6da40@redhat.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
 <05d6bc80-f34d-c128-33af-f5299ac6da40@redhat.com>
Message-ID: <SXravQZaTgbc_F5WNColvFjpENI6D8OGzo3GPEb7yPQ=.ffa0e906-9d48-4d40-ae16-63b049473f2e@github.com>

On Fri, 14 May 2021 18:31:00 GMT, Andrew Haley <aph at redhat.com> wrote:

> This looks to me like an instance of the Temporal Coupling design smell.

I would agree if we'd change the W^X as necessary before an appropriate action. But we don't, we maintain a property "JVM's runtime (C++) code runs in WXWrite" (now it is specified in one of the comments). And the change restores this property which was just broken inadvertently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3921

From dongbo at openjdk.java.net  Mon May 17 10:53:05 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 17 May 2021 10:53:05 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
Message-ID: <plnc71_wiI_RoHV--kO1R4jE7JHQ1CwIf6ZmBIcksVs=.637e5398-ce3f-403b-ae34-20f0f3e48123@github.com>

On Mon, 26 Apr 2021 11:16:00 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
>> 
>> 
>> ## reduce_add2I, before
>> mov    w10, v19.s[0]
>> mov    w2, v19.s[1]
>> add    w10, w0, w10
>> add    w10, w10, w2
>> ## reduce_add2I, optimized
>> addp   v23.2s, v24.2s, v24.2s
>> mov    w10, v23.s[0]
>> add    w10, w10, w2
>> 
>> ## reduce_max2I, before
>> dup    v16.2d, v23.d[0]
>> sminv  s16, v16.4s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> ## reduce_max2I, optimized
>> sminp  v16.2s, v23.2s, v23.2s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> 
>> 
>> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
>> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
>> 
>> 
>> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
>> # optimized
>> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
>> # default
>> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
>> 
>> 
>> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
>> 
>> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assembler tests for smaxp/sminp

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at mail.openjdk.java.net):_
> 
> On 5/10/21 6:55 AM, Dong Bo wrote:
> 
> > PING? Any comments/suggestions are appreciated.
> > Although this has been reviewed by Ningsheng, we still need help from reviewers here.
> 
> I'm testing this now.

PING? Any suggestions? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3683

From stefank at openjdk.java.net  Mon May 17 11:25:39 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 17 May 2021 11:25:39 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
Message-ID: <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>

On Fri, 14 May 2021 16:00:09 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing include

Changes requested by stefank (Reviewer).

src/hotspot/share/classfile/classLoaderData.hpp line 331:

> 329: 
> 330:   unsigned identity_hash() const {
> 331:     return (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));

LogMinObjAlignmentInBytes describes the alignment requirements for Java objects. I know that some other places in the VM reuse this for generating hash codes, but I don't think that's appropriate, and they should be cleaned out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From ayang at openjdk.java.net  Mon May 17 12:22:23 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 May 2021 12:22:23 GMT
Subject: RFR: 8267133: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java
 fails with Not expected phases: RestorePreservedMarks,
 RemoveSelfForwardingPtr: expected true, was false
Message-ID: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>

`RestorePreservedMarks`, and `RemoveSelfForwardingPtr` are conditionally emitted (only on evac failure). Updating the test to exclude these events in the assert.


double G1GCPhaseTimes::print_post_evacuate_collection_set() const {
  ...
  debug_phase(_gc_par_phases[RecalculateUsed], 1);
  if (G1CollectedHeap::heap()->evacuation_failed()) {
    debug_phase(_gc_par_phases[RemoveSelfForwardingPtr], 1);
  }

  debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
  if (G1CollectedHeap::heap()->evacuation_failed()) {
    debug_phase(_gc_par_phases[RecalculateUsed], 1);
    debug_phase(_gc_par_phases[RestorePreservedMarks], 1);
  }
  ...
}


Tested: manually set a smaller heap size to see the test fail, but pass with the PR.

-------------

Commit messages:
 - remove string dedup event
 - evac-failure

Changes: https://git.openjdk.java.net/jdk/pull/4056/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4056&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267133
  Stats: 7 lines in 2 files changed: 4 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4056.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4056/head:pull/4056

PR: https://git.openjdk.java.net/jdk/pull/4056

From zgu at openjdk.java.net  Mon May 17 12:28:45 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 17 May 2021 12:28:45 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
Message-ID: <3bDQ9FhybxaLW2WO4K2iuxiCCFM9Bfqlqext3gBbx-w=.f0cba338-246b-4022-a64e-700929c863d7@github.com>

On Thu, 29 Apr 2021 04:50:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.
> 
> Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in data holder structures which all are named "Metaspace" something and all do a very similar job. In particular, we have:
> 
> - MetaspaceSizesSnapshot (used for gc logs)
> - MetaspaceSnapshot (used in NMT)
> - MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
> - MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
> - CompressedKlassSpacePool and MetaspacePool (used for MXBeans)
> 
> As much as possible coding should be unified.
> 
> In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).
> 
> -----------------------
> 
> This patch introduces two new data holder structures:
> - `MetaspaceStats` holds reserved/committed/used counter
> - `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.
> 
> Furthermore, the patch introduces two new APIs in MetaspaceUtils:
> - `MetaspaceStats get_statistics(type)`
> - `MetaspaceCombinedStats get_combined_statistics()`
> The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.
> 
> The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:
> 
> - GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.
> 
> - NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
>    - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
>    - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
>    - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).
> 
> - jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
> 	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
> 	- I simplified the counter coding a lot. I think the complexity was not needed.
> 	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.
> 
> - `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 
> 
> - JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
> 	- I completely removed `MetaspaceSizes`
> 	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`
> 
> - MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.
> 
> - Added a simple gtest for the new APIs
> 
> Tests: 
> - manually executed hotspot tier1 tests
> - explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
> - SAP tests ran for several weeks on all our platforms

Looks good.

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3786

From tschatzl at openjdk.java.net  Mon May 17 12:45:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 May 2021 12:45:37 GMT
Subject: RFR: 8267133:
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails with Not expected
 phases: RestorePreservedMarks, RemoveSelfForwardingPtr: expected true,
 was false
In-Reply-To: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
References: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
Message-ID: <dUdhNRrfeK71PyUTRyFm2Y4b4p3Vr1_bsMb8j44aToU=.7af8cd66-cf0d-4764-9a3d-afd3b17b5801@github.com>

On Mon, 17 May 2021 11:57:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> `RestorePreservedMarks`, and `RemoveSelfForwardingPtr` are conditionally emitted (only on evac failure). Updating the test to exclude these events in the assert.
> 
> 
> double G1GCPhaseTimes::print_post_evacuate_collection_set() const {
>   ...
>   debug_phase(_gc_par_phases[RecalculateUsed], 1);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RemoveSelfForwardingPtr], 1);
>   }
> 
>   debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RecalculateUsed], 1);
>     debug_phase(_gc_par_phases[RestorePreservedMarks], 1);
>   }
>   ...
> }
> 
> 
> Tested: manually set a smaller heap size to see the test fail, but pass with the PR.

Lgtm.

Fwiw (for other reviewers), the evacuation failure phase events only now give problems because JDK-8214237 added them (in case of evac failure) but they were never posted before. Evac failure in this test is unreliable, so they are put into the `optPhases` list.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4056

From stuefe at openjdk.java.net  Mon May 17 12:49:46 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 17 May 2021 12:49:46 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <3bDQ9FhybxaLW2WO4K2iuxiCCFM9Bfqlqext3gBbx-w=.f0cba338-246b-4022-a64e-700929c863d7@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
 <3bDQ9FhybxaLW2WO4K2iuxiCCFM9Bfqlqext3gBbx-w=.f0cba338-246b-4022-a64e-700929c863d7@github.com>
Message-ID: <L2pBlWkwG9NXd3uAz-FcOBPXaC51ujVI8ucEsLPxpYY=.cc3e2874-877a-482d-949b-d7bee4fc6bf4@github.com>

On Mon, 17 May 2021 12:26:06 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Looks good.

Thanks Zhengyu!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3786

From rehn at openjdk.java.net  Mon May 17 12:55:46 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 12:55:46 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
Message-ID: <TLyPfEP5V2CczyDyW_K18NmR5Vua1Tb-46LpNDKIhyA=.0c976e23-b07b-464b-a011-f96eb5681f46@github.com>

On Thu, 13 May 2021 02:05:30 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
> 
> -Man

Hi, a couple of questions.

- The AsyncHandshakeClosure must still be on heap but when executed by a remote thread it looks like it's never deleted?
- In a normal work load there are very few handshakes, meaning there are almost never a "remote" thread.
  So if the requester uses the new AsyncHandshakeClosure, they will be almost always self/local executed.
  And there is no guarantee there will be any more handshakes, so the AsyncHandshakeClosure cannot be guaranteed to 
  finished. Since if the thread is in blocked state and there are not more handshakes it will not be executed.
  Which is the reason I did not separate them from the begging, to me it looks like very little adavantage to use 
  AsyncHandshakeClosure vs SelfExecutedHandshakeClosure.
  If you need guarantee that the handshake is executed, you cannot use AsyncHandshakeClosure and since there is almost never a remote thread and the performance difference should be very slim?

To me it sounds like you want to customize the yield method or manually loop the processing of 'normal' handshakes?

E.g. either customized yield as template or closure:
Handshake::execute(handshake, ON_YIELD); // synchronous call
Or
Handshake::enqueue(handshake);
while (!Handshake::process_handshakes(handshake)) { // Do one iteration
   // Do other stuff
}

So the processing is asynchronous but we use normal handshakes? 
(in both my examples the handshake may be on requesting threads stack, so there is no need for 'asynchronous' handshakes.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From erikj at openjdk.java.net  Mon May 17 13:03:42 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 13:03:42 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v4]
In-Reply-To: <eeemp-eAcjaVzum-WqR0XntK1GWJW51LUcZAmPVyK0k=.ce78c7c4-2efa-42de-86da-050be949f05c@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <eeemp-eAcjaVzum-WqR0XntK1GWJW51LUcZAmPVyK0k=.ce78c7c4-2efa-42de-86da-050be949f05c@github.com>
Message-ID: <sd7Z2P3OswA3Wdq9hUf4qbZ3D_39CDaQ4eCvUYkUDr8=.27e2deaf-94d0-49ac-a1a6-45d1dffb2f0c@github.com>

On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing Lib.gmk

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3638

From ayang at openjdk.java.net  Mon May 17 13:32:01 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 May 2021 13:32:01 GMT
Subject: RFR: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val in x86 code
Message-ID: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>

Removes the unnecessary push/pop instruction.

Test: hotspot_gc

-------------

Commit messages:
 - push

Changes: https://git.openjdk.java.net/jdk/pull/4063/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4063&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8230486
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4063.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4063/head:pull/4063

PR: https://git.openjdk.java.net/jdk/pull/4063

From aph at openjdk.java.net  Mon May 17 16:01:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 17 May 2021 16:01:43 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v9]
In-Reply-To: <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
Message-ID: <4KqXJjwOAZfYQGe-guwozZskn8lf2RR7oTBu5aHSUQo=.ca01baa1-601b-4cab-b546-134173ce4ce9@github.com>

On Mon, 17 May 2021 05:47:39 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> For the following benchmark:
>> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
>> 
>> The optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jmh test for Adler32

I'm not a lawyer, but Pengfei, please contribute this benchmark. All you have to do is copy it into cr.openjdk.java.net. That should be enough for someone else to take it from there. And AFAICR files should have a copyright header, which you should do too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From mcimadamore at openjdk.java.net  Mon May 17 16:03:32 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 16:03:32 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v20]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <AaNzUBQxGad7YerZ6-p7zgBeiew9UdJtaoN52fOByKI=.e6c6ea49-06b4-404e-bf20-585496430769@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue with bounded arena allocator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/352c287f..0c464221

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18-19

  Stats: 112 lines in 3 files changed: 61 ins; 37 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Mon May 17 16:08:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 16:08:17 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v21]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <CS7ZJThCZs22BgmlZjL7RIOMr-w1E3O7C4nqSalb3-M=.3fbd9b44-29b9-43f4-80d3-7fed5abb1fb4@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:

 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob
 - Address CSR comments
 - * Remove unused imports
   * Fix broken javadoc after removal of @throws clauses
   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/893e2ec1...9eb61a46

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/0c464221..9eb61a46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19-20

  Stats: 23427 lines in 753 files changed: 8549 ins; 9558 del; 5320 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From christian.beikov at gmail.com  Mon May 17 16:19:19 2021
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 17 May 2021 18:19:19 +0200
Subject: Debug NoClassDefFoundError
Message-ID: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>

Hi,

not sure if this is the right place to ask, so if I am wrong, please let 
me know where to ask this.

I have a very strange problem with a generated class defined dynamically 
into a module through `MethodHandles.Lookup.defineClass`. When I try to 
instantiate it, I get a `java.lang.NoClassDefFoundError: Could not 
initialize class ...` without any further context:


 ??? at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
 ??? at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 ??? at 
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 ??? at 
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)

Does anyone know how to further debug this? I was trying to find 
instructions for debugging the JVM itself but couldn't so far.

Regards,

Christian



From forax at univ-mlv.fr  Mon May 17 16:27:42 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 17 May 2021 18:27:42 +0200 (CEST)
Subject: Debug NoClassDefFoundError
In-Reply-To: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
Message-ID: <1751207153.871523.1621268862560.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Christian Beikov" <christian.beikov at gmail.com>
> ?: "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoy?: Lundi 17 Mai 2021 18:19:19
> Objet: Debug NoClassDefFoundError

> Hi,
> 
> not sure if this is the right place to ask, so if I am wrong, please let
> me know where to ask this.
> 
> I have a very strange problem with a generated class defined dynamically
> into a module through `MethodHandles.Lookup.defineClass`. When I try to
> instantiate it, I get a `java.lang.NoClassDefFoundError: Could not
> initialize class ...` without any further context:
> 
> 
> ??? at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> ??? at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> ??? at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> ??? at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> 
> Does anyone know how to further debug this? I was trying to find
> instructions for debugging the JVM itself but couldn't so far.

Usually is an exception inside the static block by example the block static itself not being able to load a class, that is swallowed,
putting a giant try/catch(Throwable) around the static block may help.

> 
> Regards,
> 
> Christian

regards,
R?mi

From christian.beikov at gmail.com  Mon May 17 16:40:49 2021
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 17 May 2021 18:40:49 +0200
Subject: Debug NoClassDefFoundError
In-Reply-To: <1751207153.871523.1621268862560.JavaMail.zimbra@u-pem.fr>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
 <1751207153.871523.1621268862560.JavaMail.zimbra@u-pem.fr>
Message-ID: <6d3abde5-3049-cfb5-d33c-8ba7a6b99a07@gmail.com>

Am 17.05.2021 um 18:27 schrieb Remi Forax:
> ----- Mail original -----
>> De: "Christian Beikov" <christian.beikov at gmail.com>
>> ?: "hotspot-dev" <hotspot-dev at openjdk.java.net>
>> Envoy?: Lundi 17 Mai 2021 18:19:19
>> Objet: Debug NoClassDefFoundError
>> Hi,
>>
>> not sure if this is the right place to ask, so if I am wrong, please let
>> me know where to ask this.
>>
>> I have a very strange problem with a generated class defined dynamically
>> into a module through `MethodHandles.Lookup.defineClass`. When I try to
>> instantiate it, I get a `java.lang.NoClassDefFoundError: Could not
>> initialize class ...` without any further context:
>>
>>
>>  ??? at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>>  ??? at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>  ??? at
>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>  ??? at
>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>>
>> Does anyone know how to further debug this? I was trying to find
>> instructions for debugging the JVM itself but couldn't so far.
> Usually is an exception inside the static block by example the block static itself not being able to load a class, that is swallowed,
> putting a giant try/catch(Throwable) around the static block may help.

I just tried throwing an exception in a static initializer and that 
looks different. In that case, I see where the exception comes from in 
the stack trace.

Pseudo-Code:

public class Test {
 ??? public static void main(String[] args) {
 ??????? Init.b();
 ??? }
}

class Init {
 ??? static {
 ??????? boolean a = true;
 ??????? if (a) {
 ??????????? throw new RuntimeException("Test");
 ??????? }
 ??? }
 ??? static void b() {}
}

Like I wrote, this is generated code. Apart from that, it works in 
classpath mode, which is why I suspect an issue in the VM and would like 
to understand what the reasons for that exception could be on the VM 
side or instructions on how to debug the VM.

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 16:47:49 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 16:47:49 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v9]
In-Reply-To: <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
Message-ID: <2rU8Od9JNk3hPyz6KQ2pGo-zo_Nkc0ZAviuKW0DeGGA=.830d1a33-99b2-466e-9db3-dec8ccfb0774@github.com>

On Mon, 17 May 2021 05:47:39 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jmh test for Adler32

The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 16:47:49 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 16:47:49 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v9]
In-Reply-To: <4KqXJjwOAZfYQGe-guwozZskn8lf2RR7oTBu5aHSUQo=.ca01baa1-601b-4cab-b546-134173ce4ce9@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
 <4KqXJjwOAZfYQGe-guwozZskn8lf2RR7oTBu5aHSUQo=.ca01baa1-601b-4cab-b546-134173ce4ce9@github.com>
Message-ID: <Vd-BU6aShcg0aqNhKLoUQv3qeAj3elaXeahYhtiovzo=.af74be69-596b-425c-8a88-83c012d7c1f8@github.com>

On Mon, 17 May 2021 15:58:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add jmh test for Adler32
>
> I'm not a lawyer, but Pengfei, please contribute this benchmark. All you have to do is copy it into cr.openjdk.java.net. That should be enough for someone else to take it from there. And AFAICR files should have a copyright header, which you should do too.

@theRealAph I have given attribution to Pengfei Li for the micro benchmark.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 16:56:44 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 16:56:44 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <6U5EDcQli0NUlrhdOBtzkujogfwN_39V3bPs_7oIUX0=.e51f26d8-b503-4680-8d6e-34311a1b300f@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
 <6U5EDcQli0NUlrhdOBtzkujogfwN_39V3bPs_7oIUX0=.e51f26d8-b503-4680-8d6e-34311a1b300f@github.com>
Message-ID: <WY8pBCSK_wAQVQLF_PwHI8ibrvctkfZSkvlfZ7nTtXY=.3f3ee9ce-f88f-4a0b-903e-bcad5154b354@github.com>

On Fri, 14 May 2021 20:17:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @run case
>
> Ping @pfustc about permission to add his JMH micro or write your own based on examples in `test/micro/org/openjdk/bench/java/util/`

@vnkozlov I implemented your review comments. Could you please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From forax at univ-mlv.fr  Mon May 17 16:57:48 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 17 May 2021 18:57:48 +0200 (CEST)
Subject: Debug NoClassDefFoundError
In-Reply-To: <6d3abde5-3049-cfb5-d33c-8ba7a6b99a07@gmail.com>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
 <1751207153.871523.1621268862560.JavaMail.zimbra@u-pem.fr>
 <6d3abde5-3049-cfb5-d33c-8ba7a6b99a07@gmail.com>
Message-ID: <966824.887963.1621270668463.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Christian Beikov" <christian.beikov at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoy?: Lundi 17 Mai 2021 18:40:49
> Objet: Re: Debug NoClassDefFoundError

> Am 17.05.2021 um 18:27 schrieb Remi Forax:
>> ----- Mail original -----
>>> De: "Christian Beikov" <christian.beikov at gmail.com>
>>> ?: "hotspot-dev" <hotspot-dev at openjdk.java.net>
>>> Envoy?: Lundi 17 Mai 2021 18:19:19
>>> Objet: Debug NoClassDefFoundError
>>> Hi,
>>>
>>> not sure if this is the right place to ask, so if I am wrong, please let
>>> me know where to ask this.
>>>
>>> I have a very strange problem with a generated class defined dynamically
>>> into a module through `MethodHandles.Lookup.defineClass`. When I try to
>>> instantiate it, I get a `java.lang.NoClassDefFoundError: Could not
>>> initialize class ...` without any further context:
>>>
>>>
>>>  ??? at
>>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>>  ??? at
>>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>  ??? at
>>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>  ??? at
>>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>>>
>>> Does anyone know how to further debug this? I was trying to find
>>> instructions for debugging the JVM itself but couldn't so far.
>> Usually is an exception inside the static block by example the block static
>> itself not being able to load a class, that is swallowed,
>> putting a giant try/catch(Throwable) around the static block may help.
> 
> I just tried throwing an exception in a static initializer and that
> looks different. In that case, I see where the exception comes from in
> the stack trace.

I was taking about exceptions raised by the VM not the one raised by a Java code.

R?mi


From kbarrett at openjdk.java.net  Mon May 17 18:24:47 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 17 May 2021 18:24:47 GMT
Subject: RFR: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val in x86 code
In-Reply-To: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
References: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
Message-ID: <XfQlXvzi71CJgVpSATFhW8yzo12MiHdiGFYqW87J5ZQ=.6f0d13bf-94d5-4489-8efa-404046fcad49@github.com>

On Mon, 17 May 2021 13:25:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removes the unnecessary push/pop instruction.
> 
> Test: hotspot_gc

aarch64 looks like it has the same problem.  I think other platforms don't.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4063

From xliu at openjdk.java.net  Mon May 17 18:27:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 17 May 2021 18:27:16 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Implement the new discard policy: drop the incoming message.
  
  This patch also fix a bug. meta messages append to the temp logs instead
  of directly calling output->write_blocking(). This guranatees logsites are non-blocking.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/e19e90a8..be83aafd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=14-15

  Stats: 47 lines in 3 files changed: 22 ins; 6 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 18:57:28 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 18:57:28 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v10]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <hPuHS5MP46LKwWNZTOWybZDcoW6_lLm3d4N_39wO2pA=.0b64ea8d-7f3e-440e-b9ba-2a44d7ed0a26@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
> 
> For this benchmark,  the optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Remove -XX:+UseAdler32Intrinsics, as it will fail on non-supported platforms

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/c8e2ab05..d6a58166

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806

PR: https://git.openjdk.java.net/jdk/pull/3806

From kvn at openjdk.java.net  Mon May 17 19:15:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 17 May 2021 19:15:40 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v9]
In-Reply-To: <4KqXJjwOAZfYQGe-guwozZskn8lf2RR7oTBu5aHSUQo=.ca01baa1-601b-4cab-b546-134173ce4ce9@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
 <4KqXJjwOAZfYQGe-guwozZskn8lf2RR7oTBu5aHSUQo=.ca01baa1-601b-4cab-b546-134173ce4ce9@github.com>
Message-ID: <Afbme5vB7gOTEPxY52QIAncuksoolnlYVDAE0nvfvkQ=.b8e2a409-afe1-41ff-8403-4e18165b7b13@github.com>

On Mon, 17 May 2021 15:58:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I'm not a lawyer, but Pengfei, please contribute this benchmark. All you have to do is copy it into cr.openjdk.java.net. That should be enough for someone else to take it from there. And AFAICR files should have a copyright header, which you should do too.

@theRealAph  micro is already there for long time:  https://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
It missed copyright header which is added in these changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From kvn at openjdk.java.net  Mon May 17 19:24:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 17 May 2021 19:24:41 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v10]
In-Reply-To: <hPuHS5MP46LKwWNZTOWybZDcoW6_lLm3d4N_39wO2pA=.0b64ea8d-7f3e-440e-b9ba-2a44d7ed0a26@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <hPuHS5MP46LKwWNZTOWybZDcoW6_lLm3d4N_39wO2pA=.0b64ea8d-7f3e-440e-b9ba-2a44d7ed0a26@github.com>
Message-ID: <bmfXQu7sg1_-9A8xgkWgMh3EXtSQzGxy5T3lfdBpNr0=.8fe3ba8c-58bd-4955-b5f2-acf58a847f31@github.com>

On Mon, 17 May 2021 18:57:28 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -XX:+UseAdler32Intrinsics, as it will fail on non-supported platforms

I have 2 comments.

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1322:

> 1320:     Assembler::vpmulld(dst, nds, src, vector_len);
> 1321:   }
> 1322:   void vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len, Register scratch_reg = rscratch1);

Looks like my comment was lost.
I see only last version of method is used in stub. Why you need additional 2 wrapper methods?
Also the code always pass `scratch_reg` - you don't need to set default value.

src/hotspot/cpu/x86/vm_version_x86.cpp line 907:

> 905:     }
> 906:   } else if (UseAdler32Intrinsics) {
> 907:     if (!FLAG_IS_DEFAULT(UseAdler32Intrinsics))

Add `{}`.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 20:25:59 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 20:25:59 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v10]
In-Reply-To: <bmfXQu7sg1_-9A8xgkWgMh3EXtSQzGxy5T3lfdBpNr0=.8fe3ba8c-58bd-4955-b5f2-acf58a847f31@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <hPuHS5MP46LKwWNZTOWybZDcoW6_lLm3d4N_39wO2pA=.0b64ea8d-7f3e-440e-b9ba-2a44d7ed0a26@github.com>
 <bmfXQu7sg1_-9A8xgkWgMh3EXtSQzGxy5T3lfdBpNr0=.8fe3ba8c-58bd-4955-b5f2-acf58a847f31@github.com>
Message-ID: <bsb_AOUh1uROlEjQdrpk5NnWf3TkjFE5Lt-uu9-ylfg=.0a56754d-6c0d-4760-b7d6-294c07c9eed8@github.com>

On Mon, 17 May 2021 19:21:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove -XX:+UseAdler32Intrinsics, as it will fail on non-supported platforms
>
> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1322:
> 
>> 1320:     Assembler::vpmulld(dst, nds, src, vector_len);
>> 1321:   }
>> 1322:   void vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len, Register scratch_reg = rscratch1);
> 
> Looks like my comment was lost.
> I see only last version of method is used in stub. Why you need additional 2 wrapper methods?
> Also the code always pass `scratch_reg` - you don't need to set default value.

I think the first two were introduced by other patches
will remove the scratch_reg

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From ayang at openjdk.java.net  Mon May 17 20:36:03 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 May 2021 20:36:03 GMT
Subject: RFR: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val [v2]
In-Reply-To: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
References: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
Message-ID: <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>

> Removes the unnecessary push/pop instruction.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  aarch64

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4063/files
  - new: https://git.openjdk.java.net/jdk/pull/4063/files/df025947..821a2650

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4063&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4063&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4063.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4063/head:pull/4063

PR: https://git.openjdk.java.net/jdk/pull/4063

From mgkwill at openjdk.java.net  Mon May 17 21:04:37 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 17 May 2021 21:04:37 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v37]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  kstefanj review comments
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1153/files
  - new: https://git.openjdk.java.net/jdk/pull/1153/files/6a00a18d..581346a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=36
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=35-36

  Stats: 13 lines in 2 files changed: 9 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153

PR: https://git.openjdk.java.net/jdk/pull/1153

From mgkwill at openjdk.java.net  Mon May 17 21:11:48 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 17 May 2021 21:11:48 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v37]
In-Reply-To: <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
Message-ID: <cRvaVM03ljUwa-aGYPY6zH6CXhK4hs09pHeax5Sfnnk=.84afaf57-c6fa-4eaa-a22f-345ca87a1a28@github.com>

On Mon, 17 May 2021 21:04:37 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kstefanj review comments
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/os/linux/os_linux.cpp line 3609:

> 3607:     PPC_ONLY(4 * M)
> 3608:     S390_ONLY(1 * M);
> 3609: #endif // ZERO

> Hi,
> 
> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java.
> 
> ```
> #
> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
> #  assert(div != 0) failed: lcm requires positive arguments
> #
> ```
> 
> Stack:
> 
> ```
> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
> ```
> 
> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?

@tstuefe I tried last week to reproduce the crash by faking a 64k page size in os::vm_page_size(), however I run into an error during VM initialization:


Compiling 4 files for BUILD_JIGSAW_TOOLS
Optimizing the exploded image
Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'profiled nmethods' (2496K)
gmake[3]: *** [ExplodedImageOptimize.gmk:41: /home/mgkwill/src/git/jdk/build/linux-x86_64-server-release/jdk/_optimize_image_exec.marker] Error 1
gmake[2]: *** [make/Main.gmk:440: exploded-image-optimize] Error 2
gmake[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for targets 'clean test' in configuration 'linux-x86_64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'profiled nmethods' (2496K)


I've tried to work around it, but at this point I'm not able to reproduce. Any thoughts on my theory of the cause in the above reply?

If it's not too much trouble we could test the theory by adding back the following @ line 3617 of os_linux.cpp and run linuxppc64 test again.

#ifndef ZERO
  default_large_page_size =
    AARCH64_ONLY(2 * M)
    AMD64_ONLY(2 * M)
    ARM32_ONLY(2 * M)
    IA32_ONLY(4 * M)
    IA64_ONLY(256 * M)
    PPC_ONLY(4 * M)
    S390_ONLY(1 * M);
#endif // ZERO

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

-------------

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for
 Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

-------------

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jYnPM3TGZaiZyNdO1TqYy5zWEHeqaEJH6dbp1xhiIHI=.213bd236-b2df-44d8-8f34-a963a3ffdfb6@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream<File> filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream<File> fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {


**That's all**.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From kvn at openjdk.java.net  Mon May 17 22:20:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 17 May 2021 22:20:44 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v4]
In-Reply-To: <eeemp-eAcjaVzum-WqR0XntK1GWJW51LUcZAmPVyK0k=.ce78c7c4-2efa-42de-86da-050be949f05c@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <eeemp-eAcjaVzum-WqR0XntK1GWJW51LUcZAmPVyK0k=.ce78c7c4-2efa-42de-86da-050be949f05c@github.com>
Message-ID: <j8Y800UmxSgnExaiv01EmZpQ7DJgM_hgbuAPDfco1hc=.0421a9be-598c-4b96-9cf5-af7e76dbd5ff@github.com>

On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing Lib.gmk

I reviewed only HotSpot part. Main complain is long list of library entry points (vector functions) repeated in several files. May be use macros/lambdas? with loops to reduce number of lines and consolidate in one place. Add comments explaining numbers and letters in names.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7290:

> 7288:         StubRoutines::_vector_cbrt_float128   = (address)os::dll_lookup(libsvml, "__svml_cbrtf4_ha_ex");
> 7289:         StubRoutines::_vector_cbrt_double64   = (address)os::dll_lookup(libsvml, "__svml_cbrt1_ha_ex");
> 7290:         StubRoutines::_vector_cbrt_double128  = (address)os::dll_lookup(libsvml, "__svml_cbrt2_ha_ex");

May be use macros with **comments**?  In this code is very easy make `copy-paste` errors. And It is very not clear for me what all these numbers and letters mean in names. I can guess but it should be comments.

src/hotspot/cpu/x86/x86_64.ad line 1713:

> 1711:   return OptoRegPair(hi, lo);
> 1712: }
> 1713: 

Should these methods check `EnableVectorSupport` flag too? Or `UseVectorStubs`?

src/hotspot/share/opto/callnode.cpp line 747:

> 745: 
> 746:     // If the return is in vector, compute appropriate regmask taking into account the whole range
> 747:     if(ideal_reg >= Op_VecS && ideal_reg <= Op_VecZ) {

Should this be done only for CallLeafVector?
Can `Valhalla` return big object in one of vector registers?

src/hotspot/share/opto/vectorIntrinsics.cpp line 353:

> 351:     if (operation == NULL) {
> 352:       if (C->print_intrinsics()) {
> 353:         tty->print_cr("  ** svml call failed");

Also print information about the call which fail.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1682:

> 1680:             default: Unimplemented(); break;
> 1681:           }
> 1682:         }

Macros?

src/hotspot/share/runtime/stubRoutines.cpp line 330:

> 328: address StubRoutines::_vector_atan2_double256             = NULL;
> 329: address StubRoutines::_vector_atan2_double512             = NULL;
> 330: #endif // __VECTOR_API_MATH_INTRINSICS_COMMON

Macros?

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3638

From david.holmes at oracle.com  Mon May 17 22:25:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 May 2021 08:25:31 +1000
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <tVsxY7A01RI68rqZMu8KvZkIvNyAhOlxnEQHe0TD3pI=.442d8769-50af-4be7-a6eb-4aa9d7f7343c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <c7U-QejDhMU8zQYj7MFGwxlqA5wJPu43BLsJi9B61ps=.9c9eb8b4-d44c-4c9d-a399-cc77960fa46d@github.com>
 <tVsxY7A01RI68rqZMu8KvZkIvNyAhOlxnEQHe0TD3pI=.442d8769-50af-4be7-a6eb-4aa9d7f7343c@github.com>
Message-ID: <7733bf39-b392-89fd-2a73-db0a4144e7dc@oracle.com>

On 17/05/2021 5:54 pm, Jie Fu wrote:
> On Mon, 17 May 2021 06:45:45 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Hi Jie,
>>
>> I'm not sure this is the right fix. It seems to me from the comments about having a sane addr and pc that the basic assumption/premise is that addr > pc as it is being checked when expected to be part of the current instruction. So if addr < pc I would think pc_is_near_addr should be false.
>>
>> David
> 
> Thanks @dholmes-ora for your review.
> 
> Okay, I think your suggestion is good since it just works as before and won't make things worse.
> 
> But I'm not sure whether the basic assumption/premise that `addr > pc` is always right.
> 
> Let's consider the following case
> 
> ...
>      inst1
>      inst2
>      jmp L1  <--- sizeof(jmp) = 5 bytes, the first byte is on Page k, the other 4 bytes on Page k+1
>      ...
> L1:
> 
> In this case, I think `addr` would point to some part of the jmp instruction and `pc` would point to L1, which means addr < pc.
> What do you think?

I would expect pc to point to start of jmp instruction and addr to point 
later.

David
-----

> Thanks.
> Best regards,
> Jie
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4044
> 

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <wihzX2vMKBxcpu3CE2BaQNZ1jyXj8e2Fbps1z0CJMlU=.e234b050-b1b0-4280-b764-9a409d5cf428@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From jiefu at openjdk.java.net  Mon May 17 23:14:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 17 May 2021 23:14:39 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow
In-Reply-To: <7733bf39-b392-89fd-2a73-db0a4144e7dc@oracle.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <7733bf39-b392-89fd-2a73-db0a4144e7dc@oracle.com>
Message-ID: <cR6WQIuXdTpolhWA3DUJOYCz59jNITwbeSvOzIb40VQ=.3bfb3485-abd3-44b6-b410-f0cf98b40e8e@github.com>

On Mon, 17 May 2021 22:27:16 GMT, David Holmes <david.holmes at oracle.com> wrote:

> I would expect pc to point to start of jmp instruction and addr to point
> later.

OK.
If so, the original code is right and the lasted fix just follows what it does before.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon May 17 23:30:51 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 17 May 2021 23:30:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v10]
In-Reply-To: <bsb_AOUh1uROlEjQdrpk5NnWf3TkjFE5Lt-uu9-ylfg=.0a56754d-6c0d-4760-b7d6-294c07c9eed8@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <hPuHS5MP46LKwWNZTOWybZDcoW6_lLm3d4N_39wO2pA=.0b64ea8d-7f3e-440e-b9ba-2a44d7ed0a26@github.com>
 <bmfXQu7sg1_-9A8xgkWgMh3EXtSQzGxy5T3lfdBpNr0=.8fe3ba8c-58bd-4955-b5f2-acf58a847f31@github.com>
 <bsb_AOUh1uROlEjQdrpk5NnWf3TkjFE5Lt-uu9-ylfg=.0a56754d-6c0d-4760-b7d6-294c07c9eed8@github.com>
Message-ID: <IMUWYBGC5JbRYfevjhNeDGW73aF96x416HozDTC2gtI=.1145c5f7-4eca-4441-a0bb-3d52fdd7d385@github.com>

On Mon, 17 May 2021 20:23:05 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1322:
>> 
>>> 1320:     Assembler::vpmulld(dst, nds, src, vector_len);
>>> 1321:   }
>>> 1322:   void vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len, Register scratch_reg = rscratch1);
>> 
>> Looks like my comment was lost.
>> I see only last version of method is used in stub. Why you need additional 2 wrapper methods?
>> Also the code always pass `scratch_reg` - you don't need to set default value.
>
> I think the first two were introduced by other patches
> will remove the scratch_reg

Sorry, I added first two.
The vpmulld is overloaded in base Assembler class. If I override one method in MacroAssembler class, the C++ compiler doesn?t seem to find the other overloaded functions, they somehow become hidden.
So, I need to override those as well in macroAssembler, otherwise I get the following error:
./src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp: In member function 'void C2_MacroAssembler::reduce_operation_256(BasicType, int, XMMRegister, XMMRegister, XMMRegister)':
./src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp:1573:64: error: no matching function for call to 'C2_MacroAssembler::vpmulld(XMMRegisterImpl*&, XMMRegisterImpl*&, XMMRegisterImpl*&, int&)'

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Tue May 18 00:18:08 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Tue, 18 May 2021 00:18:08 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
> 
> For this benchmark,  the optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  remove scratch register from vpmulld

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3806/files
  - new: https://git.openjdk.java.net/jdk/pull/3806/files/d6a58166..0583b2cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=09-10

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806

PR: https://git.openjdk.java.net/jdk/pull/3806

From pli at openjdk.java.net  Tue May 18 01:45:51 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Tue, 18 May 2021 01:45:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v7]
In-Reply-To: <WY8pBCSK_wAQVQLF_PwHI8ibrvctkfZSkvlfZ7nTtXY=.3f3ee9ce-f88f-4a0b-903e-bcad5154b354@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <X-vb_sDtdvtJy64EkzDrHoCJiQ6TfzxaM-PN-4eEh7k=.06e7e66f-b4cb-413b-b236-373b42109ccc@github.com>
 <6U5EDcQli0NUlrhdOBtzkujogfwN_39V3bPs_7oIUX0=.e51f26d8-b503-4680-8d6e-34311a1b300f@github.com>
 <WY8pBCSK_wAQVQLF_PwHI8ibrvctkfZSkvlfZ7nTtXY=.3f3ee9ce-f88f-4a0b-903e-bcad5154b354@github.com>
Message-ID: <-cRDqPdnR_r_5hu_J_S3oiBhuu3xFsY2dU1caSmKZ-c=.6320af8a-3c2f-436b-ab68-f5b228d26904@github.com>

On Mon, 17 May 2021 16:53:16 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Ping @pfustc about permission to add his JMH micro or write your own based on examples in `test/micro/org/openjdk/bench/java/util/`
>
> @vnkozlov I implemented your review comments. Could you please take a look.

I?ve copied @xbzhang99 's modified test case into http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java The original one w/o copyright header is backed up at http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java.old Please let me know if I should do anything else.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From ddong at openjdk.java.net  Tue May 18 02:24:41 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 18 May 2021 02:24:41 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
 <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>
Message-ID: <xju5HnlXfwTqKiQJg0yoXko0le3cQB1higMnxVPn7uk=.9d93adf3-6b7f-440e-94e7-084880674dc7@github.com>

On Mon, 17 May 2021 11:22:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing include
>
> src/hotspot/share/classfile/classLoaderData.hpp line 331:
> 
>> 329: 
>> 330:   unsigned identity_hash() const {
>> 331:     return (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
> 
> LogMinObjAlignmentInBytes describes the alignment requirements for Java objects. I know that some other places in the VM reuse this for generating hash codes, but I don't think that's appropriate, and they should be cleaned out.

Hi,
I think it makes sense.
How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From david.holmes at oracle.com  Tue May 18 02:51:17 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 May 2021 12:51:17 +1000
Subject: Debug NoClassDefFoundError
In-Reply-To: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
Message-ID: <6a8825ad-cc6a-3289-e012-f5d218ac36e0@oracle.com>

On 18/05/2021 2:19 am, Christian Beikov wrote:
> Hi,
> 
> not sure if this is the right place to ask, so if I am wrong, please let 
> me know where to ask this.
> 
> I have a very strange problem with a generated class defined dynamically 
> into a module through `MethodHandles.Lookup.defineClass`. When I try to 
> instantiate it, I get a `java.lang.NoClassDefFoundError: Could not 
> initialize class ...` without any further context:

You get that exception when a class has been placed in the erroneous 
state, which means that a previous attempt to initialize the class has 
failed. As Remi indicated if you don't see that original exception it is 
typically because something else has swallowed it. If the class is 
dynamically generated such that there is no source code for you to 
modify to debug the static initialization problem, then try running with 
-Xlog:exceptions=trace to see if that shows you what the earlier 
exception was.

Cheers,
David

> 
>  ??? at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
>  ??? at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 
> 
>  ??? at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
> 
>  ??? at 
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> 
> Does anyone know how to further debug this? I was trying to find 
> instructions for debugging the JVM itself but couldn't so far.
> 
> Regards,
> 
> Christian
> 
> 

From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <JhTe209ZxiIMoOvppz7-1xRxGS2Rb-YiyJnD7OzZDp0=.73ed4efc-2751-4746-b5d2-1bfd327574a6@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From stuefe at openjdk.java.net  Tue May 18 06:14:47 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 May 2021 06:14:47 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v37]
In-Reply-To: <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
Message-ID: <QzllwDPL826YkBLdQxK5boqdcfZjx2jhmgE26iQu1s4=.498a842c-eaee-440b-adc3-8ffdd8d15f22@github.com>

On Mon, 17 May 2021 21:04:37 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kstefanj review comments
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/os/linux/os_linux.cpp line 3751:

> 3749:     UseTransparentHugePages = false;
> 3750:     UseHugeTLBFS = false;
> 3751:     UseSHM = false;

Suggestion:

    UseSHM = false;
    if (!FLAG_IS_DEFAULT(UseLargePages)) {
      log_warning(pagesize)("UseLargePages disabled, no large pages configured and available on the system.");
    }
    UseLargePages = false;

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From stuefe at openjdk.java.net  Tue May 18 06:20:59 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 May 2021 06:20:59 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v37]
In-Reply-To: <QzllwDPL826YkBLdQxK5boqdcfZjx2jhmgE26iQu1s4=.498a842c-eaee-440b-adc3-8ffdd8d15f22@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
 <QzllwDPL826YkBLdQxK5boqdcfZjx2jhmgE26iQu1s4=.498a842c-eaee-440b-adc3-8ffdd8d15f22@github.com>
Message-ID: <PqfIgarFKhl81_ZQYXqr8HdWpFshoApqvYuc-SYpsxQ=.cddaee3a-7b24-4745-8f4f-fdfd1eae2692@github.com>

On Tue, 18 May 2021 06:11:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kstefanj review comments
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/os/linux/os_linux.cpp line 3751:
> 
>> 3749:     UseTransparentHugePages = false;
>> 3750:     UseHugeTLBFS = false;
>> 3751:     UseSHM = false;
> 
> Suggestion:
> 
>     UseSHM = false;
>     if (!FLAG_IS_DEFAULT(UseLargePages)) {
>       log_warning(pagesize)("UseLargePages disabled, no large pages configured and available on the system.");
>     }
>     UseLargePages = false;

@mgkwill Okay, that lcm assert has been embarrassingly easy to reproduce and fix (even on x64, by just setting default_large_page_size to 0). Suggested change above.

Slight beauty spot here is that we have now the large page warning spread over two places. Maybe you or @kstefanj have a better proposal. Ideally, we would
- scan default large page
- scan available page sizes
- if no default large page or no multiple page sizes or multiple page sizes do not contain default large page, bail out with error.
But I remember we were not sure if the default large page could possibly be missing from the set of large page sizes, so we correct the value further down.

So, it had nothing to do with 64k. Actually I remember trying to fake it once but since the page size goes into the alignment for committing memory, this is not so easy (we fake it on AIX because of complicated boring reasons, but there we have implicit commit on touch).

Sorry for the 64k wild goose chase.

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From stuefe at openjdk.java.net  Tue May 18 06:38:50 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 May 2021 06:38:50 GMT
Subject: RFR: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
Message-ID: <-bOCwk4gzEM_D1lsnZJQL_YGVeG7pY65oNylcC07qdY=.441a40c4-2b78-49a4-871a-90fd0f0d70b9@github.com>

On Thu, 29 Apr 2021 04:50:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.
> 
> Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in data holder structures which all are named "Metaspace" something and all do a very similar job. In particular, we have:
> 
> - MetaspaceSizesSnapshot (used for gc logs)
> - MetaspaceSnapshot (used in NMT)
> - MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
> - MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
> - CompressedKlassSpacePool and MetaspacePool (used for MXBeans)
> 
> As much as possible coding should be unified.
> 
> In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).
> 
> -----------------------
> 
> This patch introduces two new data holder structures:
> - `MetaspaceStats` holds reserved/committed/used counter
> - `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.
> 
> Furthermore, the patch introduces two new APIs in MetaspaceUtils:
> - `MetaspaceStats get_statistics(type)`
> - `MetaspaceCombinedStats get_combined_statistics()`
> The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.
> 
> The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:
> 
> - GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.
> 
> - NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
>    - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
>    - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
>    - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).
> 
> - jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
> 	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
> 	- I simplified the counter coding a lot. I think the complexity was not needed.
> 	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.
> 
> - `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 
> 
> - JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
> 	- I completely removed `MetaspaceSizes`
> 	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`
> 
> - MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.
> 
> - Added a simple gtest for the new APIs
> 
> Tests: 
> - manually executed hotspot tier1 tests
> - explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
> - SAP tests ran for several weeks on all our platforms

Okay, I waited but no more reviews are forthcoming. Our nightlies show no errors attributable to this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3786

From stuefe at openjdk.java.net  Tue May 18 06:38:52 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 May 2021 06:38:52 GMT
Subject: Integrated: 8251392: Consolidate Metaspace Statistics
In-Reply-To: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
References: <GXWRwtpSZOjwEPKp5b-0G4euKgw1nPYXgbOX8diO-8o=.e07ccfe6-e6c7-4469-b7fe-ac24ae9d70a1@github.com>
Message-ID: <YARcYjHgWASfX_cn4Y-NwEXg8hB4Y_MIBRIEVbHzW5U=.3a4c336f-cb88-4799-995d-22b827451143@github.com>

On Thu, 29 Apr 2021 04:50:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There is a lot of duplicate coding when it comes to the consumption of Metaspace Statistics.
> 
> Metaspace offers statistical APIs via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` for either the whole metaspace or non-class/class space separately. But many callers need some sort of combination of these values, which they keep in data holder structures which all are named "Metaspace" something and all do a very similar job. In particular, we have:
> 
> - MetaspaceSizesSnapshot (used for gc logs)
> - MetaspaceSnapshot (used in NMT)
> - MetaspaceSizes, MetaspaceSummary, JFRMetaspaceSummary (JFR)
> - MetaspaceCounters, CompressedClassSpaceCounters, MetaspacePerfCounters (jstat performance counters)
> - CompressedKlassSpacePool and MetaspacePool (used for MXBeans)
> 
> As much as possible coding should be unified.
> 
> In addition to that, all these callers share a common problem, in that retrieving individual statistical values via `MetaspaceUtils::(reserved|committed|used)_(words|bytes)` may yield inconsistent values. For example, "reserved" < "committed", or "committed" < "used". This is the cause of a variety of rare intermittent test errors in different areas, e.g. Performance counters (JDK-8163413, JDK-8153323), the gc log, the MemoryPoolMXBean and NMT (JDK-8237872).
> 
> -----------------------
> 
> This patch introduces two new data holder structures:
> - `MetaspaceStats` holds reserved/committed/used counter
> - `MetaspaceCombinedStats` holds an expression of these counters for class- and non-class metaspace each, as well as total counter.
> 
> Furthermore, the patch introduces two new APIs in MetaspaceUtils:
> - `MetaspaceStats get_statistics(type)`
> - `MetaspaceCombinedStats get_combined_statistics()`
> The former is used to get statistics for either non-class-space or class space; the latter gets statistics for the whole, including total values. Both APIs guarantee consistent values - reserved >= committed >= used - and never lock.
> 
> The patch uses these new data holders and these APIs to consolidate, clean up and simplify a lot of caller code, in addition to making that code resistant against inconsistent statistics:
> 
> - GC Log: class `MetaspaceSizesSnapshot` in *metaspace/metaspaceSizesSnapshot.cpp/hpp* had been used to hold metaspace statistics. Its default constructor sneakishly queried all values. `MetaspaceSizesSnapshot` has neem removed, caller code rewritten for MetaspaceCombinedStats and explicit value querying.
> 
> - NMT had class `MetaspaceSnapshot` to keep metaspace statistics and to print out baseline diffs. 
>    - `MetaspaceSizesSnapshot` was removed and replaced with `MetaspaceCombinedStats`.
>    - `MemSummaryDiffReporter::print_metaspace_diff()` has been modified: fixed a potential div-by-zero, removed the "free" statistics which is meaningless, and massaged the code a bit.
>    - Similar fixes have been done in `MemSummaryReporter::report_metadata()` (which, if backported, should fix JDK-8237872).
> 
> - jstat & co: Metaspace performance counters are realized by `MetaspaceCounters` and `CompressedClassSpaceCounters`, implementation resides in `MetaspacePerfCounters` (metaspace/metaspaceCounters.hpp/cpp). 
> 	- I completely removed `CompressedClassSpaceCounters` since there is no need for two APIs, class space is part of metaspace.
> 	- I simplified the counter coding a lot. I think the complexity was not needed.
> 	- The Metaspace counters are now retrieved in a consistent manner. This should take care of JDK-8163413, JDK-8153323 and similar bugs.
> 
> - `MetaspaceMemoryPool`, `CompressedClassSpaceMemoryPool` used in MxBeans: I changed the implementation to return consistent values. 
> 
> - JFR reports metaspace allocations (which, confusingly, uses a different terminology: "data_space" == non-class portion of metaspace). It used `MetaspaceSummary` to hold the statistics, which were composed of `MetaspaceSizes`.
> 	- I completely removed `MetaspaceSizes`
> 	- I rewrote `MetaspaceSummary` to use `MetaspaceCombinedStats`
> 
> - MetaspaceUtils::print_on() has been used to print metaspace statistics (by GCs). Function has been corrected to print consistent values.
> 
> - Added a simple gtest for the new APIs
> 
> Tests: 
> - manually executed hotspot tier1 tests
> - explicitly tested runtime/Metaspace, gc/metaspace, runtime/NMT
> - SAP tests ran for several weeks on all our platforms

This pull request has now been integrated.

Changeset: 554caf33
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/554caf33a01ac9ca2e3e9170557e8348750f3971
Stats:     593 lines in 33 files changed: 193 ins; 304 del; 96 mod

8251392: Consolidate Metaspace Statistics

Reviewed-by: coleenp, zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/3786

From iwalulya at openjdk.java.net  Tue May 18 06:57:57 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 18 May 2021 06:57:57 GMT
Subject: RFR: 8233380: CHT: Node allocation and freeing
Message-ID: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>

Hi all,

Please review this change to pass an allocator ("context") instance to the CHT at initialization instead of relying on the static configuration. The allocator instance is passed down to the allocate/free_node methods making it easier to use Arena-style allocators in the CHT.

Testing: tier1-3

-------------

Commit messages:
 - add allocator context and modify tests to match the changes

Changes: https://git.openjdk.java.net/jdk/pull/4081/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4081&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233380
  Stats: 75 lines in 7 files changed: 23 ins; 7 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4081.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4081/head:pull/4081

PR: https://git.openjdk.java.net/jdk/pull/4081

From david.holmes at oracle.com  Tue May 18 07:08:32 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 May 2021 17:08:32 +1000
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow
In-Reply-To: <cR6WQIuXdTpolhWA3DUJOYCz59jNITwbeSvOzIb40VQ=.3bfb3485-abd3-44b6-b410-f0cf98b40e8e@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <7733bf39-b392-89fd-2a73-db0a4144e7dc@oracle.com>
 <cR6WQIuXdTpolhWA3DUJOYCz59jNITwbeSvOzIb40VQ=.3bfb3485-abd3-44b6-b410-f0cf98b40e8e@github.com>
Message-ID: <a299142c-6d86-3c70-3420-20a76b2b11d7@oracle.com>

Hi Jie,

On 18/05/2021 9:14 am, Jie Fu wrote:
> On Mon, 17 May 2021 22:27:16 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> I would expect pc to point to start of jmp instruction and addr to point
>> later.
> 
> OK.
> If so, the original code is right and the lasted fix just follows what it does before.
> Thanks.

I don't know how this "pc is near addr" check ends up affecting the 
assert(left >= right) but presumably we are hitting a case where the 
addr is in fact < pc. So the question is then whether that should be 
considered "near" or not. Your original fix decided "near" means within 
15 in either direction; while under an expectation that addr >= pc, the 
current fix only consider it near within +15.

Have you analysed the original crash to check what the actual pc and 
addr values were?

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4044
> 

From rehn at openjdk.java.net  Tue May 18 07:17:39 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 18 May 2021 07:17:39 GMT
Subject: RFR: 8233380: CHT: Node allocation and freeing
In-Reply-To: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
References: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
Message-ID: <XJmWcX9CNhgB0aPnXTrfbI-TH4A98O5_4P0_lpEov7c=.9f9e650b-3c70-44da-b019-25ede65fbd89@github.com>

On Tue, 18 May 2021 06:50:23 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to pass an allocator ("context") instance to the CHT at initialization instead of relying on the static configuration. The allocator instance is passed down to the allocate/free_node methods making it easier to use Arena-style allocators in the CHT.
> 
> Testing: tier1-3

Looks okay!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4081

From iwalulya at openjdk.java.net  Tue May 18 07:17:39 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 18 May 2021 07:17:39 GMT
Subject: RFR: 8233380: CHT: Node allocation and freeing
In-Reply-To: <XJmWcX9CNhgB0aPnXTrfbI-TH4A98O5_4P0_lpEov7c=.9f9e650b-3c70-44da-b019-25ede65fbd89@github.com>
References: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
 <XJmWcX9CNhgB0aPnXTrfbI-TH4A98O5_4P0_lpEov7c=.9f9e650b-3c70-44da-b019-25ede65fbd89@github.com>
Message-ID: <HA1l7y9w3pcFm0L5hZSQ88JC2m_73z4OObg8IdLmIeA=.fdb4d199-f9fe-45ed-ada9-dc7cd1440426@github.com>

On Tue, 18 May 2021 07:12:23 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to pass an allocator ("context") instance to the CHT at initialization instead of relying on the static configuration. The allocator instance is passed down to the allocate/free_node methods making it easier to use Arena-style allocators in the CHT.
>> 
>> Testing: tier1-3
>
> Looks okay!

Thanks @robehn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4081

From jiefu at openjdk.java.net  Tue May 18 07:32:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 18 May 2021 07:32:41 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v3]
In-Reply-To: <rXnW92dGIxYAJ3xyeWc5rQabPL7txtDnFN3WNxUj9n8=.fbe1a03c-cb10-4cec-9eee-228f9b310dad@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <rXnW92dGIxYAJ3xyeWc5rQabPL7txtDnFN3WNxUj9n8=.fbe1a03c-cb10-4cec-9eee-228f9b310dad@github.com>
Message-ID: <hrCFe_k7EKO-HViOi1XAyn7Yz9q95XAGETADFoyKMcM=.6fe847b5-1e4c-4873-ae7c-e5ca63a5619e@github.com>

On Mon, 17 May 2021 09:39:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> This is a follow-up of JDK-8260046.
>> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
>> Let's fix it
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove if

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> Hi Jie,
> 
> On 18/05/2021 9:14 am, Jie Fu wrote:
> 
> > On Mon, 17 May 2021 22:27:16 GMT, David Holmes <david.holmes at oracle.com> wrote:
> > > I would expect pc to point to start of jmp instruction and addr to point
> > > later.
> > 
> > 
> > OK.
> > If so, the original code is right and the lasted fix just follows what it does before.
> > Thanks.
> 
> I don't know how this "pc is near addr" check ends up affecting the
> assert(left >= right) but presumably we are hitting a case where the
> addr is in fact < pc. So the question is then whether that should be
> considered "near" or not. Your original fix decided "near" means within
> 15 in either direction; while under an expectation that addr >= pc, the
> current fix only consider it near within +15.
> 
> Have you analysed the original crash to check what the actual pc and
> addr values were?
> 
> Thanks,
> David

The crash case should not be considered "near" since addr = 0x0, pc = 0xe66095e6.
It seems like a harmless false-positive check [1].

And the stack is like this:

Current thread (0xf5817218):  JavaThread "Unknown thread" [_thread_in_vm, id=41005, stack(0xf5907000,0xf5958000)]

Stack: [0xf5907000,0xf5958000],  sp=0xf59559f0,  free space=314k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1103c98]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x588
V  [libjvm.so+0x137209e]  JVM_handle_linux_signal+0x14e
V  [libjvm.so+0x1372313]  javaSignalHandler(int, siginfo_t*, void*)+0x23

Registers:
EAX=0xf779b000, EBX=0xf74c5ae8, ECX=0xf5817218, EDX=0xf753791c
ESP=0xf59559f0, EBP=0xf5955a58, ESI=0xe66095e6, EDI=0x00000000
EIP=0xf6b67c98, EFLAGS=0x00210213, CR2=0x00000000f779b000


Thanks.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L344

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From christian.beikov at gmail.com  Tue May 18 07:54:04 2021
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 18 May 2021 09:54:04 +0200
Subject: Debug NoClassDefFoundError
In-Reply-To: <6a8825ad-cc6a-3289-e012-f5d218ac36e0@oracle.com>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
 <6a8825ad-cc6a-3289-e012-f5d218ac36e0@oracle.com>
Message-ID: <7d132514-c1f9-20fa-8df9-39948c29deb2@gmail.com>

Thanks so much for this David Holmes! This flag is awesome!

Why are these exceptions not attached as suppressed exceptions on the 
NoClassDefFoundError? That would certainly help a lot of users. In my 
case, I am missing a few read-edges for the module descriptor.

Am 18.05.2021 um 04:51 schrieb David Holmes:
> On 18/05/2021 2:19 am, Christian Beikov wrote:
>> Hi,
>>
>> not sure if this is the right place to ask, so if I am wrong, please 
>> let me know where to ask this.
>>
>> I have a very strange problem with a generated class defined 
>> dynamically into a module through `MethodHandles.Lookup.defineClass`. 
>> When I try to instantiate it, I get a 
>> `java.lang.NoClassDefFoundError: Could not initialize class ...` 
>> without any further context:
>
> You get that exception when a class has been placed in the erroneous 
> state, which means that a previous attempt to initialize the class has 
> failed. As Remi indicated if you don't see that original exception it 
> is typically because something else has swallowed it. If the class is 
> dynamically generated such that there is no source code for you to 
> modify to debug the static initialization problem, then try running 
> with -Xlog:exceptions=trace to see if that shows you what the earlier 
> exception was.
>
> Cheers,
> David
>
>>
>> ???? at 
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
>> Method)
>> ???? at 
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 
>>
>> ???? at 
>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
>>
>> ???? at 
>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>>
>> Does anyone know how to further debug this? I was trying to find 
>> instructions for debugging the JVM itself but couldn't so far.
>>
>> Regards,
>>
>> Christian
>>
>>

From github.com+4146708+a74nh at openjdk.java.net  Tue May 18 08:05:45 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 18 May 2021 08:05:45 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <cz45_zpHWEkLSXsCH7C0zmJWDGV5gCAIEKLqs4D2is8=.08fc2fc6-83b6-48f7-9f68-be67ade893ec@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <cz45_zpHWEkLSXsCH7C0zmJWDGV5gCAIEKLqs4D2is8=.08fc2fc6-83b6-48f7-9f68-be67ade893ec@github.com>
Message-ID: <Hcv8YjiPGALgI2pKcuTSWPtpdM5w7nQFDB1ZtIbcm5g=.69b7eec2-9728-4ad6-833f-548296452b6e@github.com>

On Fri, 14 May 2021 13:12:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> src/hotspot/cpu/aarch64/pauth_aarch64.hpp line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2021, Arm Limited. All rights reserved.
> 
> This file is not a derived work of Oracle's, as far as I can see.

As I understood it, as stated in the Oracle Contributor Agreement, we share copyright with Oracle.  And as far as I can tell, Arm has always added new files with both an Arm and Oracle line (most obvious example I can find of this is cpu/aarch64/registerMap_aarch64.cpp, which has a single log entry from Nick).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From tschatzl at openjdk.java.net  Tue May 18 08:33:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 18 May 2021 08:33:38 GMT
Subject: RFR: 8233380: CHT: Node allocation and freeing
In-Reply-To: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
References: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
Message-ID: <F8S2lrxNZwNg9jHbm6ztJHnyySVJl5MctZf8vT33GjI=.c18ab98f-cac3-4850-acf3-e09980be7d51@github.com>

On Tue, 18 May 2021 06:50:23 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to pass an allocator ("context") instance to the CHT at initialization instead of relying on the static configuration. The allocator instance is passed down to the allocate/free_node methods making it easier to use Arena-style allocators in the CHT.
> 
> Testing: tier1-3

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4081

From iwalulya at openjdk.java.net  Tue May 18 08:37:44 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 18 May 2021 08:37:44 GMT
Subject: RFR: 8233380: CHT: Node allocation and freeing
In-Reply-To: <F8S2lrxNZwNg9jHbm6ztJHnyySVJl5MctZf8vT33GjI=.c18ab98f-cac3-4850-acf3-e09980be7d51@github.com>
References: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
 <F8S2lrxNZwNg9jHbm6ztJHnyySVJl5MctZf8vT33GjI=.c18ab98f-cac3-4850-acf3-e09980be7d51@github.com>
Message-ID: <REBQGJpp70oIaKy_wseOTVwfz7fSxU4F68o587dhYSo=.b6e984d1-9e03-48a0-8679-9089aabee8bd@github.com>

On Tue, 18 May 2021 08:30:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to pass an allocator ("context") instance to the CHT at initialization instead of relying on the static configuration. The allocator instance is passed down to the allocate/free_node methods making it easier to use Arena-style allocators in the CHT.
>> 
>> Testing: tier1-3
>
> Lgtm.

Thanks @tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/4081

From stefank at openjdk.java.net  Tue May 18 08:39:41 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 18 May 2021 08:39:41 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <xju5HnlXfwTqKiQJg0yoXko0le3cQB1higMnxVPn7uk=.9d93adf3-6b7f-440e-94e7-084880674dc7@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
 <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>
 <xju5HnlXfwTqKiQJg0yoXko0le3cQB1higMnxVPn7uk=.9d93adf3-6b7f-440e-94e7-084880674dc7@github.com>
Message-ID: <NhKkwi45lMXHi2gdP6xS84ZWrdun0RARI7hDM1oH7gk=.ea09d215-6cb1-44c8-a7be-04aaba7f4b4a@github.com>

On Tue, 18 May 2021 02:21:29 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderData.hpp line 331:
>> 
>>> 329: 
>>> 330:   unsigned identity_hash() const {
>>> 331:     return (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
>> 
>> LogMinObjAlignmentInBytes describes the alignment requirements for Java objects. I know that some other places in the VM reuse this for generating hash codes, but I don't think that's appropriate, and they should be cleaned out.
>
> Hi,
> I think it makes sense.
> How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch?

I created a CR for this:
https://bugs.openjdk.java.net/browse/JDK-8267303

but I still think that this usage should not be introduced in this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From yyang at openjdk.java.net  Tue May 18 08:40:15 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 18 May 2021 08:40:15 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator [v2]
In-Reply-To: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
Message-ID: <ekNrOqE-UTeqFkQqi3EUIvAGY07fivwlFMNv8Yf_3_A=.882e1bbf-ea15-496c-a067-17886056f80c@github.com>

> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>       
> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
> -  x % -y  ==> [0, y - 1] RCE
> -  x % y   ==> [0, y - 1] RCE
> -  -x % y  ==> [-y + 1, 0]
> -  -x % -y ==> [-y + 1, 0]
> 
> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
> 
> 
> for(int i=0;i<1000;i++){
>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>   ....
> }
> 
> 
> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
> 
> Testing:
> - test/hotspot/jtreg/compiler/c1/(slowdebug)

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  more comment for test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4083/files
  - new: https://git.openjdk.java.net/jdk/pull/4083/files/44ea27a7..64bdf0f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4083&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4083&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4083.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4083/head:pull/4083

PR: https://git.openjdk.java.net/jdk/pull/4083

From aph at openjdk.java.net  Tue May 18 08:52:41 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 18 May 2021 08:52:41 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <SXravQZaTgbc_F5WNColvFjpENI6D8OGzo3GPEb7yPQ=.ffa0e906-9d48-4d40-ae16-63b049473f2e@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
 <05d6bc80-f34d-c128-33af-f5299ac6da40@redhat.com>
 <SXravQZaTgbc_F5WNColvFjpENI6D8OGzo3GPEb7yPQ=.ffa0e906-9d48-4d40-ae16-63b049473f2e@github.com>
Message-ID: <noNEgeSjqooSMZIyuJNkCcOMmOAL_YivUu3GIaW0Vv0=.6760d349-1d23-4884-a61e-9beadd9364ff@github.com>

On Mon, 17 May 2021 10:43:35 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > This looks to me like an instance of the Temporal Coupling design smell.
> 
> I would agree if we'd change the W^X as necessary before an appropriate action. But we don't, we maintain a property "JVM's runtime (C++) code runs in WXWrite" (now it is specified in one of the comments). And the change restores this property which was just broken inadvertently.

Sure, but this code has not been in mainline for very long. I have no objection to this patch being committed, which is obviously necessary, but I agree with David Holmes. If we're quick we can get this fixed before it ever reaches a release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3921

From aph at openjdk.java.net  Tue May 18 08:53:42 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 18 May 2021 08:53:42 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <Hcv8YjiPGALgI2pKcuTSWPtpdM5w7nQFDB1ZtIbcm5g=.69b7eec2-9728-4ad6-833f-548296452b6e@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <cz45_zpHWEkLSXsCH7C0zmJWDGV5gCAIEKLqs4D2is8=.08fc2fc6-83b6-48f7-9f68-be67ade893ec@github.com>
 <Hcv8YjiPGALgI2pKcuTSWPtpdM5w7nQFDB1ZtIbcm5g=.69b7eec2-9728-4ad6-833f-548296452b6e@github.com>
Message-ID: <yBVjhx_H7JPM4zVMK-bDtM9Pp9cYCHVVyiEuna2ONfA=.12e4e6e4-f577-441c-a5b3-664964d17475@github.com>

On Tue, 18 May 2021 08:02:34 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/pauth_aarch64.hpp line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>>> 3:  * Copyright (c) 2021, Arm Limited. All rights reserved.
>> 
>> This file is not a derived work of Oracle's, as far as I can see.
>
> As I understood it, as stated in the Oracle Contributor Agreement, we share copyright with Oracle.  And as far as I can tell, Arm has always added new files with both an Arm and Oracle line (most obvious example I can find of this is cpu/aarch64/registerMap_aarch64.cpp, which has a single log entry from Nick).

OK. Your call, but you don't need to do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From tschatzl at openjdk.java.net  Tue May 18 08:54:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 18 May 2021 08:54:44 GMT
Subject: RFR: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val [v2]
In-Reply-To: <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>
References: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
 <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>
Message-ID: <YJfEMal90fo2EXF0myc7xFP83-Zre_y4wj0rLZ2KmBY=.c9149675-1b3d-4ee3-85ed-39fa5401cc08@github.com>

On Mon, 17 May 2021 20:36:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Removes the unnecessary push/pop instruction.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aarch64

Looks good.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4063

From github.com+4146708+a74nh at openjdk.java.net  Tue May 18 10:03:50 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 18 May 2021 10:03:50 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v2]
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

Alan Hayward has updated the pull request incrementally with two additional commits since the last revision:

 - Add pauth assert to bsd signal handler
   
   I could also add the same to windows, but the pauth functions are
   currently blank for windows.
   
   Change-Id: I1093c576ea2e9a94d0d76176d69d28fc2e5e29c1
 - Split pauth_aarch64.hpp into os_cpu variants
   
   Change-Id: Ib39f42e0ed09156b2fc861117f304ef565c25f93

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4029/files
  - new: https://git.openjdk.java.net/jdk/pull/4029/files/8ec16f50..386ee4e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=00-01

  Stats: 157 lines in 5 files changed: 134 ins; 22 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4029.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4029/head:pull/4029

PR: https://git.openjdk.java.net/jdk/pull/4029

From burban at openjdk.java.net  Tue May 18 10:03:50 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 18 May 2021 10:03:50 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <Rw1PE2-qYQ8J4SojgJ0UKa1m71wxeAkelWaS54TJIGg=.6c788d70-2afe-4545-b72f-aa39002a9b16@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>
 <oKv9Wz6-knCjz8FQJHLyeFumLz9bNCegEr_KxPrN71A=.bf5500e6-f78c-4a29-8a14-0b4eb5f1a06a@github.com>
 <Rw1PE2-qYQ8J4SojgJ0UKa1m71wxeAkelWaS54TJIGg=.6c788d70-2afe-4545-b72f-aa39002a9b16@github.com>
Message-ID: <tgo0_vGzJdK5ePegeIGChJ_BwNsBA0QR8iBVVSBWu1Q=.9f88db27-eb3c-4312-b552-79e63b519786@github.com>

On Fri, 14 May 2021 15:37:13 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> maybe it's too early as 11.4 is still beta. ( beta3 ) and java_m1 is not arm64e process (arm64e = arm64 + PAC)

I think you have to explicitly turn on arm64e on macOS, see at the bottom here: https://developer.apple.com/documentation/driverkit/debugging_and_testing_system_extensions (I have never tried it myself).

As far as I know Windows/AArch64 doesn't support PAC, so imho we don't need to do anything on Windows there in that regard. I'll ask around internally if there are any plans for PAC on Windows.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Tue May 18 10:03:51 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 18 May 2021 10:03:51 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <aIWz_KZiQLuT4f5Xtp1bOdtLHxJcvtEUwSXiR2DmHmU=.2d09c500-0227-4689-b30a-5fa49a7c40ca@github.com>

On Fri, 14 May 2021 11:22:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

* Split pauth_aarch64.hpp into os_arch variants to fix windows build
* * Windows functions are blank because no PAC on windows yet.
* Added assert in bsd signal handler

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From david.holmes at oracle.com  Tue May 18 10:10:54 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 May 2021 20:10:54 +1000
Subject: Debug NoClassDefFoundError
In-Reply-To: <7d132514-c1f9-20fa-8df9-39948c29deb2@gmail.com>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
 <6a8825ad-cc6a-3289-e012-f5d218ac36e0@oracle.com>
 <7d132514-c1f9-20fa-8df9-39948c29deb2@gmail.com>
Message-ID: <8331b2e0-ba06-b422-3dd5-d6fe80a7875e@oracle.com>

On 18/05/2021 5:54 pm, Christian Beikov wrote:
> Thanks so much for this David Holmes! This flag is awesome!
> 
> Why are these exceptions not attached as suppressed exceptions on the 
> NoClassDefFoundError? That would certainly help a lot of users. In my 
> case, I am missing a few read-edges for the module descriptor.

It has been considered, but the original exception occurred at an 
unrelated point in the program (possibly in another thread) and so it 
isn't directly a suppressed exception, nor a cause of the NCDFE. It was 
also thought that it would be quite confusing to see the stacktrace of 
another thread presented as-if it occurred in the current thread.

Cheers,
David

> Am 18.05.2021 um 04:51 schrieb David Holmes:
>> On 18/05/2021 2:19 am, Christian Beikov wrote:
>>> Hi,
>>>
>>> not sure if this is the right place to ask, so if I am wrong, please 
>>> let me know where to ask this.
>>>
>>> I have a very strange problem with a generated class defined 
>>> dynamically into a module through `MethodHandles.Lookup.defineClass`. 
>>> When I try to instantiate it, I get a 
>>> `java.lang.NoClassDefFoundError: Could not initialize class ...` 
>>> without any further context:
>>
>> You get that exception when a class has been placed in the erroneous 
>> state, which means that a previous attempt to initialize the class has 
>> failed. As Remi indicated if you don't see that original exception it 
>> is typically because something else has swallowed it. If the class is 
>> dynamically generated such that there is no source code for you to 
>> modify to debug the static initialization problem, then try running 
>> with -Xlog:exceptions=trace to see if that shows you what the earlier 
>> exception was.
>>
>> Cheers,
>> David
>>
>>>
>>> ???? at 
>>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
>>> Method)
>>> ???? at 
>>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 
>>>
>>> ???? at 
>>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
>>>
>>> ???? at 
>>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) 
>>>
>>>
>>> Does anyone know how to further debug this? I was trying to find 
>>> instructions for debugging the JVM itself but couldn't so far.
>>>
>>> Regards,
>>>
>>> Christian
>>>
>>>

From mcimadamore at openjdk.java.net  Tue May 18 10:20:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 10:20:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v22]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <aOwJzfqCiB6JW_gQSFx2GTWiM_Sfcs-_tguq5ioTVwo=.4cb0fd38-9b77-4bbc-913e-6bd05f4b3810@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/9eb61a46..f6051daf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20-21

  Stats: 32 lines in 1 file changed: 26 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From christian.beikov at gmail.com  Tue May 18 10:40:09 2021
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 18 May 2021 12:40:09 +0200
Subject: Debug NoClassDefFoundError
In-Reply-To: <8331b2e0-ba06-b422-3dd5-d6fe80a7875e@oracle.com>
References: <0163e059-05f0-bca4-affa-7e0f1f5acbe7@gmail.com>
 <6a8825ad-cc6a-3289-e012-f5d218ac36e0@oracle.com>
 <7d132514-c1f9-20fa-8df9-39948c29deb2@gmail.com>
 <8331b2e0-ba06-b422-3dd5-d6fe80a7875e@oracle.com>
Message-ID: <c780fa71-6224-1b4d-35d4-4ce46a67668f@gmail.com>

I understand. Anyway, big +1 from my side for attaching these exceptions 
somehow. That was the missing piece to understand what was wrong in my 
case. If you can't attach the exceptions, maybe the exception message 
could at least tell a user to activate this flag in order to receive 
further details? That would have been very helpful for me at least, but 
I guess also for others.

Regards,

Christian

Am 18.05.2021 um 12:10 schrieb David Holmes:
> On 18/05/2021 5:54 pm, Christian Beikov wrote:
>> Thanks so much for this David Holmes! This flag is awesome!
>>
>> Why are these exceptions not attached as suppressed exceptions on the 
>> NoClassDefFoundError? That would certainly help a lot of users. In my 
>> case, I am missing a few read-edges for the module descriptor.
>
> It has been considered, but the original exception occurred at an 
> unrelated point in the program (possibly in another thread) and so it 
> isn't directly a suppressed exception, nor a cause of the NCDFE. It 
> was also thought that it would be quite confusing to see the 
> stacktrace of another thread presented as-if it occurred in the 
> current thread.
>
> Cheers,
> David
>
>> Am 18.05.2021 um 04:51 schrieb David Holmes:
>>> On 18/05/2021 2:19 am, Christian Beikov wrote:
>>>> Hi,
>>>>
>>>> not sure if this is the right place to ask, so if I am wrong, 
>>>> please let me know where to ask this.
>>>>
>>>> I have a very strange problem with a generated class defined 
>>>> dynamically into a module through 
>>>> `MethodHandles.Lookup.defineClass`. When I try to instantiate it, I 
>>>> get a `java.lang.NoClassDefFoundError: Could not initialize class 
>>>> ...` without any further context:
>>>
>>> You get that exception when a class has been placed in the erroneous 
>>> state, which means that a previous attempt to initialize the class 
>>> has failed. As Remi indicated if you don't see that original 
>>> exception it is typically because something else has swallowed it. 
>>> If the class is dynamically generated such that there is no source 
>>> code for you to modify to debug the static initialization problem, 
>>> then try running with -Xlog:exceptions=trace to see if that shows 
>>> you what the earlier exception was.
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>> ???? at 
>>>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
>>>> Method)
>>>> ???? at 
>>>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 
>>>>
>>>> ???? at 
>>>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
>>>>
>>>> ???? at 
>>>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) 
>>>>
>>>>
>>>> Does anyone know how to further debug this? I was trying to find 
>>>> instructions for debugging the JVM itself but couldn't so far.
>>>>
>>>> Regards,
>>>>
>>>> Christian
>>>>
>>>>

From sjohanss at openjdk.java.net  Tue May 18 10:39:52 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 18 May 2021 10:39:52 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v37]
In-Reply-To: <PqfIgarFKhl81_ZQYXqr8HdWpFshoApqvYuc-SYpsxQ=.cddaee3a-7b24-4745-8f4f-fdfd1eae2692@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
 <QzllwDPL826YkBLdQxK5boqdcfZjx2jhmgE26iQu1s4=.498a842c-eaee-440b-adc3-8ffdd8d15f22@github.com>
 <PqfIgarFKhl81_ZQYXqr8HdWpFshoApqvYuc-SYpsxQ=.cddaee3a-7b24-4745-8f4f-fdfd1eae2692@github.com>
Message-ID: <Q5bNZe8-dPsyAGExe5UhFQBZcxM1n5ncuXfoPzonYI8=.ba08388a-84dc-434c-9c9d-fb40286a6e7b@github.com>

On Tue, 18 May 2021 06:16:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 3751:
>> 
>>> 3749:     UseTransparentHugePages = false;
>>> 3750:     UseHugeTLBFS = false;
>>> 3751:     UseSHM = false;
>> 
>> Suggestion:
>> 
>>     UseSHM = false;
>>     if (!FLAG_IS_DEFAULT(UseLargePages)) {
>>       log_warning(pagesize)("UseLargePages disabled, no large pages configured and available on the system.");
>>     }
>>     UseLargePages = false;
>
> @mgkwill Okay, that lcm assert has been embarrassingly easy to reproduce and fix (even on x64, by just setting default_large_page_size to 0). Suggested change above.
> 
> Slight beauty spot here is that we have now the large page warning spread over two places. Maybe you or @kstefanj have a better proposal. Ideally, we would
> - scan default large page
> - scan available page sizes
> - if no default large page or no multiple page sizes or multiple page sizes do not contain default large page, bail out with error.
> But I remember we were not sure if the default large page could possibly be missing from the set of large page sizes, so we correct the value further down.
> 
> So, it had nothing to do with 64k. Actually I remember trying to fake it once but since the page size goes into the alignment for committing memory, this is not so easy (we fake it on AIX because of complicated boring reasons, but there we have implicit commit on touch).
> 
> Sorry for the 64k wild goose chase.
> 
> Cheers, Thomas

This part of the init-step is new, before we did not treat a default large page size equal to zero to be a specific problem. It was caught later by the sanity-checks if I'm not mistaken. I wonder if we could do the same now, but I kind of like this being treated separately. 

One thing we could do to make this a little nicer is to add a function:

void warn_no_large_pages_configured() {
  if (!FLAG_IS_DEFAULT(UseLargePages)) {
    log_warning(pagesize)("UseLargePages disabled, no large pages configured and available on the system.");
  }
}

We could then call that function from both here: 

if (default_large_page_size == 0) {
  // No large pages configured, return.
  warn_no_large_pages_configured();
  UseLargePages = false;
  UseTransparentHugePages = false;
  UseHugeTLBFS = false;
  UseSHM = false;
}

And at the end of `setup_large_page_type()`:

  ...
  warn_no_large_pages_configured();
  return false;
}

What do you guys think about that @tstuefe and @mgkwill?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From stuefe at openjdk.java.net  Tue May 18 10:58:46 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 May 2021 10:58:46 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v37]
In-Reply-To: <PqfIgarFKhl81_ZQYXqr8HdWpFshoApqvYuc-SYpsxQ=.cddaee3a-7b24-4745-8f4f-fdfd1eae2692@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <0mQ1LPby_gqOsdO5oAZe-pMfLte8wExE8SsbqOUa740=.34f162e0-3665-494c-884b-d856574782e1@github.com>
 <QzllwDPL826YkBLdQxK5boqdcfZjx2jhmgE26iQu1s4=.498a842c-eaee-440b-adc3-8ffdd8d15f22@github.com>
 <PqfIgarFKhl81_ZQYXqr8HdWpFshoApqvYuc-SYpsxQ=.cddaee3a-7b24-4745-8f4f-fdfd1eae2692@github.com>
Message-ID: <UJwqQroAQsp2enco83ylNSxbdftqfvvCyh51HAHfE3w=.b7f17c92-25e1-4eda-a8b8-cd76bfe55784@github.com>

On Tue, 18 May 2021 06:16:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 3751:
>> 
>>> 3749:     UseTransparentHugePages = false;
>>> 3750:     UseHugeTLBFS = false;
>>> 3751:     UseSHM = false;
>> 
>> Suggestion:
>> 
>>     UseSHM = false;
>>     if (!FLAG_IS_DEFAULT(UseLargePages)) {
>>       log_warning(pagesize)("UseLargePages disabled, no large pages configured and available on the system.");
>>     }
>>     UseLargePages = false;
>
> @mgkwill Okay, that lcm assert has been embarrassingly easy to reproduce and fix (even on x64, by just setting default_large_page_size to 0). Suggested change above.
> 
> Slight beauty spot here is that we have now the large page warning spread over two places. Maybe you or @kstefanj have a better proposal. Ideally, we would
> - scan default large page
> - scan available page sizes
> - if no default large page or no multiple page sizes or multiple page sizes do not contain default large page, bail out with error.
> But I remember we were not sure if the default large page could possibly be missing from the set of large page sizes, so we correct the value further down.
> 
> So, it had nothing to do with 64k. Actually I remember trying to fake it once but since the page size goes into the alignment for committing memory, this is not so easy (we fake it on AIX because of complicated boring reasons, but there we have implicit commit on touch).
> 
> Sorry for the 64k wild goose chase.
> 
> Cheers, Thomas

> What do you guys think about that @tstuefe and @mgkwill?

Makes sense, I thought the same.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From ddong at openjdk.java.net  Tue May 18 11:39:04 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 18 May 2021 11:39:04 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9]
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <gWqimOho65l_cm0ub7jE2Op-ayWhXpRIsr7AoV3cHBM=.131f808f-fd6e-4d48-bfd6-b7b39047bf0a@github.com>

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  remote LogMinObjAlignmentInBytes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3901/files
  - new: https://git.openjdk.java.net/jdk/pull/3901/files/e9c674ca..cbed0208

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3901.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901

PR: https://git.openjdk.java.net/jdk/pull/3901

From ddong at openjdk.java.net  Tue May 18 11:39:04 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 18 May 2021 11:39:04 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <NhKkwi45lMXHi2gdP6xS84ZWrdun0RARI7hDM1oH7gk=.ea09d215-6cb1-44c8-a7be-04aaba7f4b4a@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
 <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>
 <xju5HnlXfwTqKiQJg0yoXko0le3cQB1higMnxVPn7uk=.9d93adf3-6b7f-440e-94e7-084880674dc7@github.com>
 <NhKkwi45lMXHi2gdP6xS84ZWrdun0RARI7hDM1oH7gk=.ea09d215-6cb1-44c8-a7be-04aaba7f4b4a@github.com>
Message-ID: <-2ELEmM_1ZSALHkM1TJH_DYWaP69ZIsgOCXZVBsVv8Q=.b2440c88-d860-4813-a970-3f9a4c46c9e8@github.com>

On Tue, 18 May 2021 08:37:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hi,
>> I think it makes sense.
>> How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch?
>
> I created a CR for this:
> https://bugs.openjdk.java.net/browse/JDK-8267303
> 
> but I still think that this usage should not be introduced in this patch.

okay, removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From coleenp at openjdk.java.net  Tue May 18 11:45:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 18 May 2021 11:45:43 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <-2ELEmM_1ZSALHkM1TJH_DYWaP69ZIsgOCXZVBsVv8Q=.b2440c88-d860-4813-a970-3f9a4c46c9e8@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
 <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>
 <xju5HnlXfwTqKiQJg0yoXko0le3cQB1higMnxVPn7uk=.9d93adf3-6b7f-440e-94e7-084880674dc7@github.com>
 <NhKkwi45lMXHi2gdP6xS84ZWrdun0RARI7hDM1oH7gk=.ea09d215-6cb1-44c8-a7be-04aaba7f4b4a@github.com>
 <-2ELEmM_1ZSALHkM1TJH_DYWaP69ZIsgOCXZVBsVv8Q=.b2440c88-d860-4813-a970-3f9a4c46c9e8@github.com>
Message-ID: <Vz-yzueyNej4KLVf7Y3jaFpQ45QomOv-x24HLCU5xhI=.b7d2d9f6-ae33-4d78-8f4e-be3b34f99969@github.com>

On Tue, 18 May 2021 11:33:41 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> I created a CR for this:
>> https://bugs.openjdk.java.net/browse/JDK-8267303
>> 
>> but I still think that this usage should not be introduced in this patch.
>
> okay, removed.

This seems fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
Message-ID: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From neliasso at openjdk.java.net  Tue May 18 13:24:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 18 May 2021 13:24:40 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator [v2]
In-Reply-To: <ekNrOqE-UTeqFkQqi3EUIvAGY07fivwlFMNv8Yf_3_A=.882e1bbf-ea15-496c-a067-17886056f80c@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <ekNrOqE-UTeqFkQqi3EUIvAGY07fivwlFMNv8Yf_3_A=.882e1bbf-ea15-496c-a067-17886056f80c@github.com>
Message-ID: <pxG0a2MK_C3BOBE2NvRwu9YytlA1-TERmsbFYIxDNzY=.69d06375-f541-4b4f-b46e-e71ffce18a19@github.com>

On Tue, 18 May 2021 08:40:15 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>>       
>> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
>> -  x % -y  ==> [0, y - 1] RCE
>> -  x % y   ==> [0, y - 1] RCE
>> -  -x % y  ==> [-y + 1, 0]
>> -  -x % -y ==> [-y + 1, 0]
>> 
>> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
>> 
>> 
>> for(int i=0;i<1000;i++){
>>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>>   ....
>> }
>> 
>> 
>> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
>> 
>> Testing:
>> - test/hotspot/jtreg/compiler/c1/(slowdebug)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment for test

Have you checked how C2 handles this case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4083

From kbarrett at openjdk.java.net  Tue May 18 13:55:43 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 18 May 2021 13:55:43 GMT
Subject: RFR: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val [v2]
In-Reply-To: <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>
References: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
 <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>
Message-ID: <fU5w7mjH58AGqK-08fnOSjpBpooytfoA3UFiMgWZ1j0=.4fa2a72e-5d9c-4a23-878a-d0f1881f9ff0@github.com>

On Mon, 17 May 2021 20:36:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Removes the unnecessary push/pop instruction.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aarch64

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4063

From ayang at openjdk.java.net  Tue May 18 14:01:45 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 May 2021 14:01:45 GMT
Subject: Integrated: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val
In-Reply-To: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
References: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
Message-ID: <IvdIgh3xbnPNRdV3NbqvIyM1P_1zeVLMvaJuV8KswNM=.ca8e4f49-eda1-4ac2-82a7-4b4dda918453@github.com>

On Mon, 17 May 2021 13:25:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removes the unnecessary push/pop instruction.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: f8f40ab2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f8f40ab25ffce0243a40f307b0341cddd12ccb5d
Stats:     3 lines in 2 files changed: 0 ins; 2 del; 1 mod

8230486: G1BarrierSetAssembler::g1_write_barrier_post unnecessarily pushes/pops new_val

Reviewed-by: kbarrett, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/4063

From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
Message-ID: <LP-JXhyiYZ4-yfHkeHX7Rqt-1AnCPesIf4uK5ycC8B4=.4459bddf-cc61-4c92-9b5e-4e046ede8a90@github.com>

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From ayang at openjdk.java.net  Tue May 18 14:01:45 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 May 2021 14:01:45 GMT
Subject: RFR: 8230486: G1BarrierSetAssembler::g1_write_barrier_post
 unnecessarily pushes/pops new_val [v2]
In-Reply-To: <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>
References: <dUVGS6Yv7_GpC4rOaLuTmbLTYmrlhB3E44zMClXpBak=.ddd05c5e-f1cd-4660-ad7e-4679f97c8e16@github.com>
 <vVkc-m9rQJgWcvnAIvyIYl72QWWJNqMMS-oLqtlVlXY=.84fd8502-6f96-4518-a908-359076397dd6@github.com>
Message-ID: <teAuy7vcBZq98qtrZHIicnOuZYtMGszplkRm2S7fFw4=.702dc7e4-5da0-46f6-9376-fd3852cdd261@github.com>

On Mon, 17 May 2021 20:36:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Removes the unnecessary push/pop instruction.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aarch64

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4063

From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
Message-ID: <z9kXH2Zm9AgECH3iihoXcgKisBj7HQMYB7SBmr98Hek=.c0ba0d9d-f3ea-427c-97a1-8de5843c0698@github.com>

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From thartmann at openjdk.java.net  Tue May 18 15:11:44 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 18 May 2021 15:11:44 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator [v2]
In-Reply-To: <ekNrOqE-UTeqFkQqi3EUIvAGY07fivwlFMNv8Yf_3_A=.882e1bbf-ea15-496c-a067-17886056f80c@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <ekNrOqE-UTeqFkQqi3EUIvAGY07fivwlFMNv8Yf_3_A=.882e1bbf-ea15-496c-a067-17886056f80c@github.com>
Message-ID: <kKEk2dUYu4C5YnGbpZnT1_DGLelmjcJ37Quq6WVqrn4=.89fa6bd8-ea23-42db-b1b9-634d7be5645c@github.com>

On Tue, 18 May 2021 08:40:15 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>>       
>> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
>> -  x % -y  ==> [0, y - 1] RCE
>> -  x % y   ==> [0, y - 1] RCE
>> -  -x % y  ==> [-y + 1, 0]
>> -  -x % -y ==> [-y + 1, 0]
>> 
>> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
>> 
>> 
>> for(int i=0;i<1000;i++){
>>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>>   ....
>> }
>> 
>> 
>> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
>> 
>> Testing:
>> - test/hotspot/jtreg/compiler/c1/(slowdebug)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment for test

Looks like C2 does not implement this optimization (should be in `ModINode::Value`). We should add it.

src/hotspot/share/c1/c1_RangeCheckElimination.cpp line 246:

> 244:         _bound = new Bound();
> 245:       }
> 246:     }else {

Missing whitespace `}else`

-------------

Changes requested by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4083

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
Message-ID: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
 <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <UN8g8sgK7nXvYjtZiSBUhCaU-0qEb8b7Y2OzhxgtOzY=.08a47c9a-a7a5-4a0e-8919-19d71fc19a4f@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <LgbU-sI0tWPZUqtoQA3U69H6-_YB1kKmqgTckkVcrlo=.0d7b35c2-aec5-41be-ab62-459a9ae8c7dd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <NQ4IhVZC8LudCe-a1JsSFd95dtttKo46bw2iK0DkiQA=.1139a6e3-8acc-4099-b9ab-c599fdca20d2@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <Ep1azxH_vnemjxbvBu6HprCKjwMcG1nzTozdYIA1RtU=.e8be0928-e09f-483e-a775-06bbcce8be8c@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <L_strZt1H9X1vdJh8AYRIWExhJMfmODbsj-N8xQkvYw=.1e46863a-db33-4d33-bbe4-645f0c52b349@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jVoctx_UzYbZpnzVpQJ-kVkDSiW8wpixKMGGDicrAfk=.e36178c6-303c-489c-813b-37842a110503@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
Message-ID: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From akozlov at openjdk.java.net  Tue May 18 18:51:25 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 18 May 2021 18:51:25 GMT
Subject: RFR: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS [v2]
In-Reply-To: <j3JiorbScoe0O2DZezRaE8MmzNQgcOqsfo7t-tc6vkY=.0c68c157-70eb-4e53-a614-283b2ec69374@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
 <j3JiorbScoe0O2DZezRaE8MmzNQgcOqsfo7t-tc6vkY=.0c68c157-70eb-4e53-a614-283b2ec69374@github.com>
Message-ID: <Pe0mNW1eGt7tLhG7AzuF4SzpVU1GUo0xBU9T2x6usYo=.1c57649b-808d-4fa0-94e3-e6145d9aeb83@github.com>

On Tue, 11 May 2021 15:09:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
>> 
>> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments

OK, thanks! I still don't think there is something needs fixing, but a consensus is necessary, I agree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3921

From manc at openjdk.java.net  Tue May 18 18:55:05 2021
From: manc at openjdk.java.net (Man Cao)
Date: Tue, 18 May 2021 18:55:05 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
Message-ID: <8rPWuMhzFXiMsKI-nux3Dlp9ZLd2fzCMLiop7PuyuHA=.78de892c-12a9-41bb-b00d-39c559301db4@github.com>

On Thu, 13 May 2021 02:05:30 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
> 
> -Man

Thanks for the feedback!

For David's question, I'm looking for adding support for HandshakeState::try_process() to execute non-self executable async handshakes . The caller of try_process() could be the VM thread, or a third thread, or the original requesting thread. 

Consider this scenario:

Thread A calls Handshake::enqueue(async_op, Thread_B);
Thread X calls Handshake::execute(sync_op, Thread_B);

Thread X could be the same as thread A, or a third thread C. In either case, X can execute any non-self executable handshake op on B's queue if it is safe to do so. Currently only synchronous handshake can be executed.

The goal is to support asynchronous handshake with all threads for JDK-8236485, and skipping threads that are blocked, without entering a safepoint in the requesting thread. The requesting thread can stop waiting if it has timed out. I experimented that it could work with some modification to the handshake code.

A minimal requirement is to be able to safely check if the target thread is blocked, and skip them. This was disussed in https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-April/034697.html. 
The first four if conditions in HandshakeState::try_process() already check for this condition, provided that there is at least one non-self executable handshake op on the queue so that HandshakeState::claim_handshake() can return true. I'd like to extract the four if conditions in a single public method in JDK-8236485.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From akozlov at openjdk.java.net  Tue May 18 18:58:30 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 18 May 2021 18:58:30 GMT
Subject: Integrated: 8265292: [macos_aarch64] java/foreign/TestDowncall.java
 crashes with SIGBUS
In-Reply-To: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
References: <o3OYonwtQLsB4V-8mXpGWf8gc-YmIfhxeuFuLhlY3_E=.88f4e1c3-d8c5-4376-a656-a634ed9193d6@github.com>
Message-ID: <zuLt8HxiPrde0UTbIkvkZUXOGZ1_Ga3xx31qhTlEZQ8=.3cf8bbc0-8319-43ad-aaa2-b3700840165a@github.com>

On Fri, 7 May 2021 15:38:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a fix for the intermittent crash. It is caused by a mistake in the ProgrammableInvoker::invoke_native, the wrong order of W^X and JavaThread state transition. We need WXExec since we are about to call a generated stub. But we need to switch to WXExec only after JavaThread state change. The thread state change may trigger a safepoint, that would need to do bookkeeping in the codecache (MarkActivationClosure::do_code_blob from the bug). So the fix is to change JavaThread state first, then change WX.
> 
> The fix was verified with the help of https://bugs.openjdk.java.net/browse/JDK-8266742. The new check catches all test failures reported by 8265292, 8265183, 8265182. I've verified tests pass after the fix with that new check enabled.

This pull request has now been integrated.

Changeset: b92c5a44
Author:    Anton Kozlov <akozlov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b92c5a44f268c3a866fa6bc6f6218abc0457e689
Stats:     16 lines in 3 files changed: 12 ins; 4 del; 0 mod

8265292: [macos_aarch64] java/foreign/TestDowncall.java crashes with SIGBUS
8265183: [macos_aarch64] java/foreign/TestIntrinsics.java crashes with SIGBUS
8265182: [macos_aarch64] java/foreign/TestUpcall.java crashes with SIGBUS

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3921

From manc at openjdk.java.net  Tue May 18 19:08:08 2021
From: manc at openjdk.java.net (Man Cao)
Date: Tue, 18 May 2021 19:08:08 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
Message-ID: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>

> Hi all,
> 
> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
> 
> -Man

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Added missing deallocation and renamed "remote" to "non-self".

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4005/files
  - new: https://git.openjdk.java.net/jdk/pull/4005/files/2e113fd0..01f4d3ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4005&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4005&range=00-01

  Stats: 15 lines in 2 files changed: 4 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4005/head:pull/4005

PR: https://git.openjdk.java.net/jdk/pull/4005

From manc at openjdk.java.net  Tue May 18 19:26:38 2021
From: manc at openjdk.java.net (Man Cao)
Date: Tue, 18 May 2021 19:26:38 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <6upsotssnsrV8Lf8nwKPHT4VvfFXhdS8oZFKptSDs7E=.b87cb421-0244-4916-bb0a-eceefdc6c60c@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

I addressed the comments in the second commit.

For Robbin's question:
> The AsyncHandshakeClosure must still be on heap but when executed by a remote thread it looks like it's never deleted?

Great catch! Added delete in HandshakeState::try_process() similarly to HandshakeState::process_self_inner().

> If you need guarantee that the handshake is executed, you cannot use AsyncHandshakeClosure and since there is almost never a remote thread and the performance difference should be very slim?

I hope the reply to David could also answer this. I don't need a guarantee that the handshake is executed. I mainly need a safe approach to skip target threads that are blocked. Reusing the four if checks in HandshakeState::try_process() is a possible approach, and it would need async non-self executable handshake for HandshakeState::claim_handshake() to return true.

> To me it sounds like you want to customize the yield method or manually loop the processing of 'normal' handshakes?

Yes, that could work as well. I did find the "async" name confusing. If we support `Handshake::enqueue(handshake)` for 'normal' handshakes, it is basically an async submission of the 'normal' handshake. It also has the problem of how to deallocate the `HandshakeOperation` object, which is currently handled by `AsyncHandshakeOperation`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From github.com+2249648+johntortugo at openjdk.java.net  Tue May 18 19:57:51 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 18 May 2021 19:57:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
Message-ID: <ONFiZvz_NQIpysXV36O-_jnkchrFU9lWZR9yDAQ69-Q=.4d5806dc-a641-43f9-a5de-3afd997e3e76@github.com>

On Tue, 18 May 2021 00:18:08 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove scratch register from vpmulld

src/hotspot/cpu/x86/assembler_x86.cpp line 7859:

> 7857: void Assembler::vbroadcastf128(XMMRegister dst, Address src, int vector_len) {
> 7858:   assert(VM_Version::supports_avx(), "");
> 7859:   assert(vector_len == AVX_256bit, "");

Looks like "vector_len" can only be AVX_256bit. Do we really need a parameter then?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Tue May 18 21:01:51 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Tue, 18 May 2021 21:01:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <ONFiZvz_NQIpysXV36O-_jnkchrFU9lWZR9yDAQ69-Q=.4d5806dc-a641-43f9-a5de-3afd997e3e76@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
 <ONFiZvz_NQIpysXV36O-_jnkchrFU9lWZR9yDAQ69-Q=.4d5806dc-a641-43f9-a5de-3afd997e3e76@github.com>
Message-ID: <3u4Jng7rm3u0yIMbNRVKk4w5MewUeJ_KVNryPBAi6xI=.0b0d52b9-ab33-443c-83d0-54cb5512c286@github.com>

On Tue, 18 May 2021 19:45:52 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove scratch register from vpmulld
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 7859:
> 
>> 7857: void Assembler::vbroadcastf128(XMMRegister dst, Address src, int vector_len) {
>> 7858:   assert(VM_Version::supports_avx(), "");
>> 7859:   assert(vector_len == AVX_256bit, "");
> 
> Looks like "vector_len" can only be AVX_256bit. Do we really need a parameter then?

your are right, for now it can only be AVX_256bit. But I think in the future other lengths will be used too. So we should have a more generic signature.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
 <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
Message-ID: <NsAoXUFxz2QHQKrDb3O1Ls1jKyXBkfbmB9AubjXUDus=.6a87197e-b3bf-4971-a48e-6e7f008c9135@github.com>

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Sean, Phil and Alan

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01

  Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From bchristi at openjdk.java.net  Tue May 18 21:23:08 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 18 May 2021 21:23:08 GMT
Subject: RFR: 8266936: Add a finalization JFR event
Message-ID: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>

Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
(The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)

The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.

The Category for the event:
`"Java Virtual Machine" / "GC" / "Finalization"`
is what made sense to me, even though the event is generated from library code.

Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
Automated testing looks good so far.

Thanks,
-Brent

-------------

Commit messages:
 - Fix jcheck some more
 - Fix jcheck
 - Merge branch 'master' into 8266936
 - Add jfr mode to test/jdk/java/lang/ref/FinalizeOverride.java
 - Fix spacing in new regtest
 - Remove extraneous comments from new regtest
 - Removed unintentional changes from FinalizeOverride.java
 - Actually check in new regtest
 - Update TestActiveSettingEvent.java
 - Update TestDefaultConfigurations.java and .jfc files
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e6705c0e...200268ab

Changes: https://git.openjdk.java.net/jdk/pull/4101/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266936
  Stats: 191 lines in 11 files changed: 190 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4101.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101

PR: https://git.openjdk.java.net/jdk/pull/4101

From github.com+6502015+ineuwirth at openjdk.java.net  Tue May 18 21:43:48 2021
From: github.com+6502015+ineuwirth at openjdk.java.net (Istvan Neuwirth)
Date: Tue, 18 May 2021 21:43:48 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
Message-ID: <GJ6CiNHpqUF7NrQ_ewfxWn0Vbf4-t5463A-l76tOf9Q=.d7fb0161-f8b6-423f-9961-e2e3bc055ca0@github.com>

On Tue, 18 May 2021 20:55:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
> 
> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
> 
> The Category for the event:
> `"Java Virtual Machine" / "GC" / "Finalization"`
> is what made sense to me, even though the event is generated from library code.
> 
> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
> Automated testing looks good so far.
> 
> Thanks,
> -Brent

test/jdk/jdk/jfr/event/gc/finalization/TestFinalizerEvent.java line 48:

> 46: 
> 47: public class TestFinalizerEvent {
> 48:     static boolean finalizerRun = false;

Should not this be a `volatile` field? (Or alternatively, using `AtomicBoolean`). As the `finalize` is invoked on the finalizer thread, the other thread executing the test might not see the change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust order of VM options

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From bchristi at openjdk.java.net  Tue May 18 22:27:37 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 18 May 2021 22:27:37 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: <GJ6CiNHpqUF7NrQ_ewfxWn0Vbf4-t5463A-l76tOf9Q=.d7fb0161-f8b6-423f-9961-e2e3bc055ca0@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <GJ6CiNHpqUF7NrQ_ewfxWn0Vbf4-t5463A-l76tOf9Q=.d7fb0161-f8b6-423f-9961-e2e3bc055ca0@github.com>
Message-ID: <RiKpkHZ0dD2t0dProw2u2A6E5LnCVg0tUUI1fJx-ddg=.5d1e8b33-1de3-4892-8459-36a28347a4a7@github.com>

On Tue, 18 May 2021 21:40:57 GMT, Istvan Neuwirth <github.com+6502015+ineuwirth at openjdk.org> wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> test/jdk/jdk/jfr/event/gc/finalization/TestFinalizerEvent.java line 48:
> 
>> 46: 
>> 47: public class TestFinalizerEvent {
>> 48:     static boolean finalizerRun = false;
> 
> Should not this be a `volatile` field? (Or alternatively, using `AtomicBoolean`). As the `finalize` is invoked on the finalizer thread, the other thread executing the test might not see the change.

Good idea, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From kvn at openjdk.java.net  Tue May 18 22:38:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 18 May 2021 22:38:45 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
Message-ID: <ZZrdeV5Y7nexsygFo4bCHj6QlXM6LxISZkFBwEkIX74=.001d0fb0-516d-4b0d-a026-49bedad9ca2d@github.com>

On Tue, 18 May 2021 00:18:08 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove scratch register from vpmulld

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3806

From bchristi at openjdk.java.net  Tue May 18 22:41:06 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 18 May 2021 22:41:06 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
Message-ID: <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>

> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
> 
> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
> 
> The Category for the event:
> `"Java Virtual Machine" / "GC" / "Finalization"`
> is what made sense to me, even though the event is generated from library code.
> 
> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
> Automated testing looks good so far.
> 
> Thanks,
> -Brent

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Test flag should be volatile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4101/files
  - new: https://git.openjdk.java.net/jdk/pull/4101/files/200268ab..e0ef383b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4101.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101

PR: https://git.openjdk.java.net/jdk/pull/4101

From sviswanathan at openjdk.java.net  Tue May 18 23:27:13 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 18 May 2021 23:27:13 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v5]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <BAQwqe-KQSmKpNgVGJ5NxOKzlA2AJ0lAJVhTizAvuhg=.a581fe64-15e5-48ef-a44c-bd4e6f878448@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

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/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/01a549e4..9021a15c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=03-04

  Stats: 1220 lines in 8 files changed: 48 ins; 1104 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Tue May 18 23:43:13 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 18 May 2021 23:43:13 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v6]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Print intrinsic fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/9021a15c..11528426

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=04-05

  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Tue May 18 23:59:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 18 May 2021 23:59:30 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v6]
In-Reply-To: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com>
Message-ID: <kuPisFfDih5I9wdNv-74nvIHh5rIcaXNa9Yc2SQ0ucA=.0ec83051-e1cc-44a8-82ab-9f386fb4b614@github.com>

On Tue, 18 May 2021 23:43:13 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print intrinsic fix

@vnlozlov I have implemented all the review comments. Please let me know if the changes look ok to you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Tue May 18 23:59:28 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 18 May 2021 23:59:28 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v7]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  jcheck fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/11528426..0d1d0382

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=05-06

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From kvn at openjdk.java.net  Wed May 19 00:30:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 19 May 2021 00:30:42 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v7]
In-Reply-To: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com>
Message-ID: <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com>

On Tue, 18 May 2021 23:59:28 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fixes

This is much much better! Thank you for changing it. I am only asking now to add comment explaining names.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6975:

> 6973:     if (libsvml != NULL) {
> 6974:       log_info(library)("Loaded library %s, handle " INTPTR_FORMAT, JNI_LIB_PREFIX "svml" JNI_LIB_SUFFIX, p2i(libsvml));
> 6975:       if (UseAVX > 2) {

Please add comment here explaining naming convention you are using here. 
What `f16_ha_z0` mean? Why `8_ha_z0` and not `d8_ha_z0`?
What is `l9`, `e9`, `ex`?

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Wed May 19 00:58:15 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 00:58:15 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v8]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <eO_1qWe-MFy5w38OWfxt_zNFjEx5nmLokTaIkRn1n0Y=.5eb763f6-4e88-401d-9700-21e309d4cd23@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Add comments explaining naming convention

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/0d1d0382..45f20a34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=06-07

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Wed May 19 00:58:18 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 00:58:18 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v7]
In-Reply-To: <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com>
 <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com>
Message-ID: <UVQzm-_gzEOO25bIz-WMkBXDCEvqZLhg2ovWJyVzO4g=.1f4bd39d-4f09-4947-bf12-18b4eb1b9f1b@github.com>

On Wed, 19 May 2021 00:26:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jcheck fixes
>
> This is much much better! Thank you for changing it. I am only asking now to add comment explaining names.

@vnkozlov I have added comments explaining naming convention. Please let me know if this looks ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From kvn at openjdk.java.net  Wed May 19 01:07:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 19 May 2021 01:07:42 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v8]
In-Reply-To: <eO_1qWe-MFy5w38OWfxt_zNFjEx5nmLokTaIkRn1n0Y=.5eb763f6-4e88-401d-9700-21e309d4cd23@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <eO_1qWe-MFy5w38OWfxt_zNFjEx5nmLokTaIkRn1n0Y=.5eb763f6-4e88-401d-9700-21e309d4cd23@github.com>
Message-ID: <tOvB1ChHgSZ6GuktNwD9sYBiLfhTlFUBJi66foBFRRE=.20332807-84b4-4545-ac5a-a63533ff00d8@github.com>

On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments explaining naming convention

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Wed May 19 01:31:40 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 01:31:40 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v8]
In-Reply-To: <eO_1qWe-MFy5w38OWfxt_zNFjEx5nmLokTaIkRn1n0Y=.5eb763f6-4e88-401d-9700-21e309d4cd23@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <eO_1qWe-MFy5w38OWfxt_zNFjEx5nmLokTaIkRn1n0Y=.5eb763f6-4e88-401d-9700-21e309d4cd23@github.com>
Message-ID: <wsbufRmPyQRPJ8TcLoYPKEsXwyv1iQeHy_cwerYjxII=.9390a448-2371-4823-b5ad-39b911ae9ccb@github.com>

On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments explaining naming convention

Thanks a lot Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From yyang at openjdk.java.net  Wed May 19 02:42:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 19 May 2021 02:42:03 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator if divisor
 is IntConstant [v3]
In-Reply-To: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
Message-ID: <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>

> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>       
> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
> -  x % -y  ==> [0, y - 1] RCE
> -  x % y   ==> [0, y - 1] RCE
> -  -x % y  ==> [-y + 1, 0]
> -  -x % -y ==> [-y + 1, 0]
> 
> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
> 
> 
> for(int i=0;i<1000;i++){
>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>   ....
> }
> 
> 
> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
> 
> Testing:
> - test/hotspot/jtreg/compiler/c1/(slowdebug)

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  missing whitespace; more comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4083/files
  - new: https://git.openjdk.java.net/jdk/pull/4083/files/64bdf0f2..35aaa375

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4083&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4083&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4083.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4083/head:pull/4083

PR: https://git.openjdk.java.net/jdk/pull/4083

From yyang at openjdk.java.net  Wed May 19 02:42:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 19 May 2021 02:42:04 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator if divisor
 is IntConstant [v2]
In-Reply-To: <kKEk2dUYu4C5YnGbpZnT1_DGLelmjcJ37Quq6WVqrn4=.89fa6bd8-ea23-42db-b1b9-634d7be5645c@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <ekNrOqE-UTeqFkQqi3EUIvAGY07fivwlFMNv8Yf_3_A=.882e1bbf-ea15-496c-a067-17886056f80c@github.com>
 <kKEk2dUYu4C5YnGbpZnT1_DGLelmjcJ37Quq6WVqrn4=.89fa6bd8-ea23-42db-b1b9-634d7be5645c@github.com>
Message-ID: <gzpGRlTLWiZL07rQZORVfKe5EYZMKz_3JQi7bohp_hI=.a86613ec-c3a9-4327-92c2-0f9eea65e2be@github.com>

On Tue, 18 May 2021 14:44:46 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more comment for test
>
> src/hotspot/share/c1/c1_RangeCheckElimination.cpp line 246:
> 
>> 244:         _bound = new Bound();
>> 245:       }
>> 246:     }else {
> 
> Missing whitespace `}else`

> Looks like C2 does not implement this optimization (should be in ModINode::Value). We should add it.

Thanks for confirming the C2 part, I will double-check it and file an issue for that~

> Missing whitespace }else

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4083

From sviswanathan at openjdk.java.net  Wed May 19 03:37:11 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 03:37:11 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v9]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <IZCPfVXiQLsnfq98MOqZ9pOJH0SzvXb_dwZ_RZAZQgc=.40effb0c-fc0b-4ba5-8c91-a32b02447cb8@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  fix 32-bit build

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/45f20a34..f7e39913

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From chris at sageembedded.com  Wed May 19 05:31:52 2021
From: chris at sageembedded.com (Chris Cole)
Date: Tue, 18 May 2021 22:31:52 -0700
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
Message-ID: <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>

Hi All,

I have continued to further investigate this bug that I reported and
have some additional information.

I believe that this issue is similar to JDK-8153107  "enabling
ObjectSynchronizer::quick_enter() on ARM64 causes hangs" (see [1]),
this impacted C2 on both ARM32 and ARM64. The fix for that issue (see
[2]) fixed MacroAssembler::fast_lock() that is used by C2. When this
fix was made, I believe only C2 was using
ObjectSynchronizer::quick_enter(). Now (version 11.0.10+ and 15+) that
C1 is using ObjectSynchronizer::quick_enter() due to JDK-8241234, a
similar change to C1_MacroAssembler::lock_object() used by C1 is
required. The following change to unconditionally store to the
displaced header field should fix things for C1.

diff --git a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
index 9d5c82dceb9..9a628eb7de5 100644
--- a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
+++ b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
@@ -235,7 +235,8 @@ int C1_MacroAssembler::lock_object(Register hdr,
Register obj,
   sub(tmp2, hdr, SP, eq);
   movs(tmp2, AsmOperand(tmp2, lsr, exact_log2(os::vm_page_size())), eq);
   // If 'eq' then OK for recursive fast locking: store 0 into a lock record.
-  str(tmp2, Address(disp_hdr, mark_offset), eq);
+  // set to non zero otherwise (see discussion in JDK-8267042)
+  str(tmp2, Address(disp_hdr, mark_offset));
   b(fast_lock_done, eq);
   // else need slow case
   b(slow_case);

This should fix the specific issue that I was seeing and that is
reproduce with test case I provided.

I also reviewed the code to see if there were any other possible issue
related to Runtime1::monitorenter() not always initializing displaced
header field due to ObjectSynchronizer::quick_enter(). I found that if
the -XX:-UseFastLocking develop flag is used (C1 doesn't use any
inline monitor lock/unlock code and just calls the
Runtime1::monitorenter() and Runtime1::monitorexit()), then the test
case will reproduce deadlock on any of the platforms (arm32, aarch64,
x86_64, etc) due to uninitialized displaced header field. Here is a
fix for that. (Note that this change below, makes the change above to
c1_MacroAssembler_arm.cpp unnecessary).

diff --git a/src/hotspot/share/runtime/synchronizer.cpp
b/src/hotspot/share/runtime/synchronizer.cpp
index 98afe838c49..db3eb255778 100644
--- a/src/hotspot/share/runtime/synchronizer.cpp
+++ b/src/hotspot/share/runtime/synchronizer.cpp
@@ -355,11 +355,6 @@ bool ObjectSynchronizer::quick_enter(oop obj, Thread* self,
     // Case: light contention possibly amenable to TLE
     // Case: TLE inimical operations such as nested/recursive synchronization

-    if (owner == self) {
-      m->_recursions++;
-      return true;
-    }
-
     // This Java Monitor is inflated so obj's header will never be
     // displaced to this thread's BasicLock. Make the displaced header
     // non-NULL so this BasicLock is not seen as recursive nor as
@@ -372,6 +367,11 @@ bool ObjectSynchronizer::quick_enter(oop obj, Thread* self,
     // and last are the inflated Java Monitor (ObjectMonitor) checks.
     lock->set_displaced_header(markWord::unused_mark());

+    if (owner == self) {
+      m->_recursions++;
+      return true;
+    }
+
     if (owner == NULL && m->try_set_owner_from(NULL, self) == NULL) {
       assert(m->_recursions == 0, "invariant");
       return true;

I am also reviewing the biased_locking_enter() call from
C1_MacroAssembler::lock_object(), this code path can call
Runtime1::monitorenter() without initializing the displaced header
field. But in this code path it might not be possible for
ObjectSynchronizer::quick_enter() to return "true" without calling
lock->set_displaced_header(markWord::unused_mark()), this would
require current thread to own inflated monitor which seems to not be
possible in this case when biased_locking_enter() is calling
Runtime1::monitorenter().

Anyway, I will continue to review the code to make sure this aren't
any other issues related to this issue.

Thanks,
Chris

[1] https://bugs.openjdk.java.net/browse/JDK-8153107
[2] http://hg.openjdk.java.net/jdk/jdk/rev/3e66d204af9b

On Wed, May 12, 2021 at 8:58 PM Chris Cole <chris at sageembedded.com> wrote:
>
> Hi Dan,
>
> Great, thanks! Feel free to contact me if there is anything else I can
> do that is helpful.
>
> Chris
>
> On Wed, May 12, 2021 at 10:21 AM <daniel.daugherty at oracle.com> wrote:
> >
> > Hi Chris,
> >
> > I filed the following new bug on your behalf:
> >
> > JDK-8267042 bug in monitor locking/unlocking on ARM32 C1 due to
> > uninitialized BasicObjectLock::_displaced_header
> > https://bugs.openjdk.java.net/browse/JDK-8267042
> >
> > Dan
> >
> >
> > On 5/12/21 1:02 PM, Chris Cole wrote:
> > > Hi,
> > >
> > > Not sure if this is the appropriate place or method to report an OpenJDK
> > > bug, if not please advise.
> > >
> > > I have discovered a bug with ARM32 C1 monitor locking/unlocking that can
> > > result in deadlock. The bug was introduced with JCK-8241234 "Unify monitor
> > > enter/exit runtime entries" [1]. This change introduced a call to
> > > ObjectSynchronizer::quick_entry() within the logic for
> > > Runtime1::monitorenter().
> > > If the monitor is inflated and already owned by the current thread, then
> > > ObjectSynchronizer::quick_entry() simply increments
> > > ObjectMonitor::_recursions and returns. In this case
> > > Runtime1::monitorenter() returns to the JIT compiled code without calling
> > > "lock->set_displaced_header(markWord::unused_mark())" (see [2]). For ARM32
> > > the _displaced_header field is not always initialized in JIT code before
> > > calling Runtime1::monitorenter() helper. If the uninitialized value of
> > > _displaced_header field on stack happens to be NULL, this causes an issue
> > > because the JIT code to exit the monitor first checks for a NULL
> > > _displaced_header as an indication for non-inflated recursive locking which
> > > is a noop for exiting the monitor (see [3]). This means that the
> > > Runtime1::monitorexit() helper is not called as required to exit this
> > > inflated monitor, and the ObjectMonitor::_recursions is not decremented as
> > > required. This leads to thread not unlocking the monitor when required and
> > > deadlock when another thread tries to lock the monitor.
> > >
> > > This bug is not present on AArch64 and x86, because the displaced header is
> > > initialized in JIT code with the "unlocked object header" value (which is
> > > non-zero) before calling Runtime1::monitorenter() helper (see [4] and [5]).
> > > Note sure about other CPU architectures.
> > >
> > > I see two ways to fix this.
> > > 1) In ObjectSynchronizer::quick_entry() move the
> > > "lock->set_displaced_header(markWord::unused_mark())" statement to before
> > > the "if (owner == current)" at line 340 in share/runtime/synchronizer.cpp
> > > (see [6]), so that Runtime1::monitorenter() helper logic always initializes
> > > the displaced header field as was the case before JCK-8241234.
> > > 2) For ARM32 add JIT code to initialize the displaced header field before
> > > calling Runtime1::monitorenter() helper as done for AArch64 and x86.
> > >
> > > Not sure which is better (or maybe both are required for some reason I am
> > > not aware of). I believe this "displacted header" on the stack can be
> > > looked at by stack walkers but I am not familiar with the exact details and
> > > if there are implications on this fix.
> > >
> > > The bug is also present in OpenJDK 11.0.10 and later (introduced by the
> > > backport of JDK-8241234 [1]).
> > >
> > > I/my company (Sage Embedded Software) has signed the Oracle Contributor
> > > Agreement (OCA) and have been granted access to JCK.
> > >
> > > The bug can be reproduced in my environment with the OpenJDK Community TCK
> > > testing of java.io.PipedReader that deadlocks, but because reproduction of
> > > the issue requires uninitialized stack field to be zero, it might not
> > > happen in some environments. I have a Java test case that can reproduce
> > > this issue on ARM in 32 bit mode. It is pasted inline below at the end of
> > > the email. There is a "getZeroOnStack()" method that I think helps get a
> > > zero into the uninitialized _displaced_header field. The test case source
> > > code is copied from OpenJDK java.io.PipedReader source code and then
> > > modified. It needs to be run with only C1 enabled (I am using minimal
> > > variant to enforce this) and the following command line options
> > > (-XX:-BackgroundCompilation -XX:CompileThreshold=500
> > > -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"). The test
> > > case should run and then end with "Source thread done" and "Reading
> > > complete" output if the bug is not reproduced. If the monitor bug is
> > > reproduced the test case will not exit and the main thread will be
> > > deadlocked, with the main thread last printing "read() before wait" and
> > > missing "read() after wait" and "Reading complete". If useful I can provide
> > > the output of this test cause including -XX:PrintAssebly and logging that I
> > > added to ObjectSynchronizer::quick_entry() that shows uninitialized
> > > lock->_displaced_header and ObjectMonitor->_recursions continue to get
> > > incremented (into the 1000s) as the MonitorBugTest.receive() method is
> > > called in a loop.
> > >
> > > Please let me know if there is anything else that would be helpful. I hope
> > > to become active in the OpenJDK Community. My time is a little limited at
> > > the moment, so sometimes it might take a day to respond (I have 3 and 6
> > > year old kids). In the coming years I expect to have additional time to be
> > > more involved in the OpenJDK Community.
> > >
> > > Best regards,
> > > Chris Cole
> > > Sage Embedded Software LLC
> > >
> > > [1] https://bugs.openjdk.java.net/browse/JDK-8241234
> > > [2]
> > > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L343
> > > [3]
> > > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L130
> > > [4]
> > > https://github.com/openjdk/jdk/blob/71b8ad45b4de6836e3bb2716ebf136f3f8ea2198/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp#L95
> > > [5]
> > > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74
> > > [6]
> > > https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L340
> > >
> > > /*
> > >   * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights
> > > reserved.
> > >   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> > >   *
> > >   * This code is free software; you can redistribute it and/or modify it
> > >   * under the terms of the GNU General Public License version 2 only, as
> > >   * published by the Free Software Foundation.  Oracle designates this
> > >   * particular file as subject to the "Classpath" exception as provided
> > >   * by Oracle in the LICENSE file that accompanied this code.
> > >   *
> > >   * This code is distributed in the hope that it will be useful, but WITHOUT
> > >   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > >   * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> > >   * version 2 for more details (a copy is included in the LICENSE file that
> > >   * accompanied this code).
> > >   *
> > >   * You should have received a copy of the GNU General Public License version
> > >   * 2 along with this work; if not, write to the Free Software Foundation,
> > >   * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> > >   *
> > >   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> > >   * or visit www.oracle.com if you need additional information or have any
> > >   * questions.
> > >   */
> > >
> > > package com.sageembedded.test;
> > >
> > > import java.io.IOException;
> > > import java.io.InterruptedIOException;
> > >
> > > /*
> > >   * java -cp bin -minimal -XX:-BackgroundCompilation -XX:CompileThreshold=500
> > >   *  -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"
> > >   *  -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
> > >   *  com.sageembedded.test.MonitorBugTest
> > >   */
> > > public class MonitorBugTest {
> > >
> > >          private static int DATA_SIZE = 1000;
> > >          private static int BUFFER_SIZE = 256;
> > >
> > >          private char buffer[] = new char[BUFFER_SIZE];
> > >          private int writeIndex = -1;
> > >          private int readIndex = 0;
> > >
> > >          public Object lock = new Object();
> > >
> > >          public static void main(String[] args) {
> > >                  MonitorBugTest test = new MonitorBugTest();
> > >                  test.run();
> > >          }
> > >          private void run() {
> > >                  System.out.println("Starting test");
> > >
> > >                  SourceThread source = new SourceThread();
> > >                  source.start();
> > >
> > >                  try {
> > >                          for (int i = 0; i < DATA_SIZE; i++) {
> > >                                  read();
> > >                          }
> > >                  } catch (IOException e) {
> > >                          e.printStackTrace();
> > >                  }
> > >                  System.out.println("Reading complete");
> > >
> > >          }
> > >
> > >          synchronized void receive(char data[], int offset, int length)
> > > throws IOException {
> > >                  while (--length >= 0) {
> > >                          getZeroOnStack(offset);
> > >                          receive(data[offset++]);
> > >                  }
> > >          }
> > >
> > >          private void getZeroOnStack(int offset) {
> > >                  int l1;
> > >                  int l2;
> > >                  int l3;
> > >                  int l4;
> > >                  int l5;
> > >                  int l6;
> > >                  int l7;
> > >                  int l8;
> > >                  int l9;
> > >                  int l10;
> > >                  int l11;
> > >                  int l12;
> > >                  int l13;
> > >                  int l14;
> > >                  int l15;
> > >                  int l16;
> > >
> > >                  l1 = 0;
> > >                  l2 = 0;
> > >                  l3 = 0;
> > >                  l4 = 0;
> > >                  l5 = 0;
> > >                  l6 = 0;
> > >                  l7 = 0;
> > >                  l8 = 0;
> > >                  l9 = 0;
> > >                  l10 = 0;
> > >                  l11 = 0;
> > >                  l12 = 0;
> > >                  l13 = 0;
> > >                  l14 = 0;
> > >                  l15 = 0;
> > >                  l16 = 0;
> > >          }
> > >
> > >          synchronized void receive(int c) throws IOException {
> > >                  while (writeIndex == readIndex) {
> > >                          notifyAll();
> > >                          try {
> > >                                  wait(1000);
> > >                          } catch (InterruptedException e) {
> > >                                  throw new InterruptedIOException();
> > >                          }
> > >                  }
> > >                  if (writeIndex < 0) {
> > >                          writeIndex = 0;
> > >                          readIndex = 0;
> > >                  }
> > >                  buffer[writeIndex++] = (char) c;
> > >                  if (writeIndex >= buffer.length) {
> > >                          writeIndex = 0;
> > >                  }
> > >          }
> > >
> > >          synchronized void last() {
> > >                  notifyAll();
> > >          }
> > >          public synchronized int read() throws IOException {
> > >                  while (writeIndex < 0) {
> > >                          notifyAll();
> > >                          try {
> > >                                  System.out.println("read() before wait");
> > >                                  wait(1000);
> > >                                  System.out.println("read() after wait");
> > >                          } catch (InterruptedException e) {
> > >                                  throw new InterruptedIOException();
> > >                          }
> > >                  }
> > >                  int value = buffer[readIndex++];
> > >                  if (readIndex >= buffer.length) {
> > >                          readIndex = 0;
> > >                  }
> > >                  if (writeIndex == readIndex) {
> > >                          writeIndex = -1;
> > >                  }
> > >                  return value;
> > >          }
> > >
> > >          private class SourceThread extends Thread {
> > >                  @Override
> > >                  public void run() {
> > >                          System.out.println("Source thread start");
> > >                          char data[] = new char[DATA_SIZE];
> > >                          try {
> > >                                  receive(data, 0, data.length);
> > >                                  last();
> > >                          } catch (IOException e) {
> > >                                  e.printStackTrace();
> > >                          }
> > >                          System.out.println("Source thread done");
> > >                  }
> > >          }
> > > }
> >

From egahlin at openjdk.java.net  Wed May 19 06:23:39 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 May 2021 06:23:39 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
Message-ID: <ayNpMzF6ka22KwVWuY8Zp81jc56_R9R6oMi4aMP0C0k=.53fc629d-e7b9-4320-a0f9-a7ffd26cc8c4@github.com>

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

This looks useful, but I am worried about the performance impact:

- The added allocation for every object that is finalized. 
- The event being enabled in the default configuration. 

The default configuration must be safe to use even in pathological cases, i.e. an application with lots of objects being finalized. It's probably too much overhead (or number of events) for the profile configuration as well.

There is also the added startup cost of JFR. One event may not matter that much, but they all add up. We need to put in place a mechanism that doesn't rely on bytecode instrumentation at runtime. There is an enhancement for that, but it requires some engineering first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From rehn at openjdk.java.net  Wed May 19 06:24:41 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 19 May 2021 06:24:41 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <6upsotssnsrV8Lf8nwKPHT4VvfFXhdS8oZFKptSDs7E=.b87cb421-0244-4916-bb0a-eceefdc6c60c@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
 <6upsotssnsrV8Lf8nwKPHT4VvfFXhdS8oZFKptSDs7E=.b87cb421-0244-4916-bb0a-eceefdc6c60c@github.com>
Message-ID: <vrJamdZZHB6bYV_dPcUn4hlFBXVmUmotb_YmQX9gJF4=.cfb536fd-912b-45bd-b2fb-4583370a155f@github.com>

On Tue, 18 May 2021 19:23:40 GMT, Man Cao <manc at openjdk.org> wrote:

> I addressed the comments in the second commit.
> 
> For Robbin's question:
> 
> > The AsyncHandshakeClosure must still be on heap but when executed by a remote thread it looks like it's never deleted?
> 
> Great catch! Added delete in HandshakeState::try_process() similarly to HandshakeState::process_self_inner().
> 
> > If you need guarantee that the handshake is executed, you cannot use AsyncHandshakeClosure and since there is almost never a remote thread and the performance difference should be very slim?
> 
> I hope the reply to David could also answer this. I don't need a guarantee that the handshake is executed. I mainly need a safe approach to skip target threads that are blocked. Reusing the four if checks in HandshakeState::try_process() is a possible approach, and it would need async non-self executable handshake for HandshakeState::claim_handshake() to return true.
> 
> > To me it sounds like you want to customize the yield method or manually loop the processing of 'normal' handshakes?
> 
> Yes, that could work as well. I did find the "async" name confusing. If we support `Handshake::enqueue(handshake)` for 'normal' handshakes, it is basically an async submission of the 'normal' handshake. It also has the problem of how to deallocate the `HandshakeOperation` object, which is currently handled by `AsyncHandshakeOperation`.

Ok, I think I got what you are trying todo.
But if you don't need it to be execute and you are fine with it being never execute, you also must not enqueue more.
Since it's never executed it will never be freed, thus we are leaking memory every time one is enqueued.
Which means the issuer of the handshakes must keep track of what threads that have not completed it's previous async handshake and avoid enqueue more.

Since we don't want to do this, I'm guessing, you could processes them with VM thread during the the safepoint synchronization (in this time slot where we often end up yielding the VM thread).
As long as you promise to safepoint and processes them there, if needed, we are not leaking.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From alanb at openjdk.java.net  Wed May 19 06:55:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 19 May 2021 06:55:39 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <ayNpMzF6ka22KwVWuY8Zp81jc56_R9R6oMi4aMP0C0k=.53fc629d-e7b9-4320-a0f9-a7ffd26cc8c4@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
 <ayNpMzF6ka22KwVWuY8Zp81jc56_R9R6oMi4aMP0C0k=.53fc629d-e7b9-4320-a0f9-a7ffd26cc8c4@github.com>
Message-ID: <WMOxoYcu9vz07nEFpQhNsPmC_ner7QPLHlD6ap2cFsA=.7c1e64d6-012e-4042-b67b-013ca5197d4e@github.com>

On Wed, 19 May 2021 06:20:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> This looks useful, but I am worried about the performance impact:
> 
> * The added allocation for every object that is finalized.
> * The event being enabled in the default configuration.
> 
> The default configuration must be safe to use even in pathological cases, i.e. an application with lots of objects being finalized. It's probably too much overhead (or number of events) for the profile configuration as well.
> 
> There is also the added startup cost of JFR. One event may not matter that much, but they all add up. We need to put in place a mechanism that doesn't rely on bytecode instrumentation at runtime. There is an enhancement for that, but it requires some engineering first.

I'm a bit worried by this too. Does it need to be enabled by default? Can we put a static final instance of FinalizerEvent in that class that can be used to test if the event is enabled so that it doesn't create a FinalizerEvent when disabled?

Is it worth exploring doing have an event in the VM, in register_finalizer, instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From david.holmes at oracle.com  Wed May 19 07:02:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 May 2021 17:02:31 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <8rPWuMhzFXiMsKI-nux3Dlp9ZLd2fzCMLiop7PuyuHA=.78de892c-12a9-41bb-b00d-39c559301db4@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <8rPWuMhzFXiMsKI-nux3Dlp9ZLd2fzCMLiop7PuyuHA=.78de892c-12a9-41bb-b00d-39c559301db4@github.com>
Message-ID: <60f6530d-94e7-cb7c-590c-42e1263b4678@oracle.com>

Hi Man,

On 19/05/2021 4:55 am, Man Cao wrote:
> On Thu, 13 May 2021 02:05:30 GMT, Man Cao <manc at openjdk.org> wrote:
> 
>> Hi all,
>>
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>>
>> -Man
> 
> Thanks for the feedback!
> 
> For David's question, I'm looking for adding support for HandshakeState::try_process() to execute non-self executable async handshakes . The caller of try_process() could be the VM thread, or a third thread, or the original requesting thread.
> 
> Consider this scenario:
> 
> Thread A calls Handshake::enqueue(async_op, Thread_B);
> Thread X calls Handshake::execute(sync_op, Thread_B);
> 
> Thread X could be the same as thread A, or a third thread C. In either case, X can execute any non-self executable handshake op on B's queue if it is safe to do so. Currently only synchronous handshake can be executed.

Thanks for clarifying the usage scenario. I have a better understanding 
now of what you want to allow. Being able to process an async op on 
behalf of Thread B so that you can then process your own sync op, makes 
sense. Though if there is a self-only async op in the queue ahead of 
that, then you won't be able to proceed anyway.

> The goal is to support asynchronous handshake with all threads for JDK-8236485, and skipping threads that are blocked, without entering a safepoint in the requesting thread. The requesting thread can stop waiting if it has timed out. I experimented that it could work with some modification to the handshake code.

Not really getting this part. Why do you want to skip blocked threads? I 
read the brief discussion you mention below and it seems Erik asked the 
same question and I don't understand your answer - if a thread is 
blocked then it is handshake-safe and so the handshake should be fast. 
Or are you concerned that your handshake won't be able to proceed 
because of what else may be in a target thread's op queue, and you want 
to skip that target in that case?

Thanks,
David
-----


> A minimal requirement is to be able to safely check if the target thread is blocked, and skip them. This was disussed in https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-April/034697.html.
> The first four if conditions in HandshakeState::try_process() already check for this condition, provided that there is at least one non-self executable handshake op on the queue so that HandshakeState::claim_handshake() can return true. I'd like to extract the four if conditions in a single public method in JDK-8236485.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From egahlin at openjdk.java.net  Wed May 19 07:54:09 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 May 2021 07:54:09 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
Message-ID: <cwQrJqXGscoP-cf3HWcWTwW_nGiebz0p_UdgFip7Ed4=.1eb4cad1-7808-46dd-9b2c-96e15b4b35a5@github.com>

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

I wonder if there needs to be one event per finalized object?

Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great. 

Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From iwalulya at openjdk.java.net  Wed May 19 08:04:38 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 19 May 2021 08:04:38 GMT
Subject: Integrated: 8233380: CHT: Node allocation and freeing
In-Reply-To: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
References: <xXW4iPV1Z7PR9mb_jbQVsRFJIZj4vebgMc_8GO5sV1w=.d732d716-08e8-483b-bf22-4460247584b3@github.com>
Message-ID: <rtqojqU6xfaidR8FCh-VyOoLPxxdwrjjWeZIeQH5vg8=.efe86ba7-b280-4850-b241-24fe8c16f9c6@github.com>

On Tue, 18 May 2021 06:50:23 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to pass an allocator ("context") instance to the CHT at initialization instead of relying on the static configuration. The allocator instance is passed down to the allocate/free_node methods making it easier to use Arena-style allocators in the CHT.
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: 70f6c670
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70f6c67051135ff1d9994089b88d8ea630932046
Stats:     75 lines in 7 files changed: 23 ins; 7 del; 45 mod

8233380: CHT: Node allocation and freeing

Reviewed-by: rehn, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/4081

From vlivanov at openjdk.java.net  Wed May 19 08:10:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 19 May 2021 08:10:43 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v9]
In-Reply-To: <IZCPfVXiQLsnfq98MOqZ9pOJH0SzvXb_dwZ_RZAZQgc=.40effb0c-fc0b-4ba5-8c91-a32b02447cb8@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <IZCPfVXiQLsnfq98MOqZ9pOJH0SzvXb_dwZ_RZAZQgc=.40effb0c-fc0b-4ba5-8c91-a32b02447cb8@github.com>
Message-ID: <rKFcN9W1q5QAwboWcu3bglJfX7rZCjakcPZZS_6LBCQ=.1649b3ad-fccb-4412-8c6e-50d28281f0d1@github.com>

On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix 32-bit build

Overall, looks fine.

src/hotspot/cpu/x86/x86_64.ad line 1704:

> 1702: }
> 1703: 
> 1704: void Matcher::vector_calling_convention(VMRegPair *regs, uint num_bits, uint total_args_passed) {

You can just remove `Matcher::vector_calling_convention()` and call `SharedRuntime::vector_calling_convention()` directly.

src/hotspot/share/opto/matcher.cpp line 1370:

> 1368:       VMReg first = parm_regs[i].first();
> 1369:       VMReg second = parm_regs[i].second();
> 1370:       if( !first->is_valid() &&

Please, fix formatting.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1355:

> 1353: 
> 1354:   // Get address for svml method.
> 1355:   get_svml_address(vector_api_op_id, vt->length_in_bytes() * BitsPerByte, bt, name, 100, &addr);

Any particular reason to return the address as an out argument and not directly (`address addr = get_svml_address(...)`)?

src/hotspot/share/utilities/globalDefinitions_vecApi.hpp line 34:

> 32: // VS2017 required to build .s files for math intrinsics
> 33: #if defined(_WIN64) && (defined(_MSC_VER) && (_MSC_VER >= 1910))
> 34: #define __VECTOR_API_MATH_INTRINSICS_COMMON

Considering the stubs are not part of JVM anymore, the macros can go away. The stubs are dynamically linked now and if there's no library built/present the linking will fail.

And then `globalDefinitions_vecApi.hpp` becomes empty and can be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From thartmann at openjdk.java.net  Wed May 19 08:17:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 May 2021 08:17:42 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator if divisor
 is IntConstant [v3]
In-Reply-To: <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
Message-ID: <tVaaLlZjca5fPyplFXzGb1yKNYEZLJ2dgM_GxbrEiSE=.980467a2-aecc-43e2-91da-0bc13911fde5@github.com>

On Wed, 19 May 2021 02:42:03 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>>       
>> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
>> -  x % -y  ==> [0, y - 1] RCE
>> -  x % y   ==> [0, y - 1] RCE
>> -  -x % y  ==> [-y + 1, 0]
>> -  -x % -y ==> [-y + 1, 0]
>> 
>> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
>> 
>> 
>> for(int i=0;i<1000;i++){
>>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>>   ....
>> }
>> 
>> 
>> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
>> 
>> Testing:
>> - test/hotspot/jtreg/compiler/c1/(slowdebug)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing whitespace; more comment

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4083

From neliasso at openjdk.java.net  Wed May 19 08:28:43 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 19 May 2021 08:28:43 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator if divisor
 is IntConstant [v3]
In-Reply-To: <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
Message-ID: <wdDxDcWTXFZM3DJkjgINY1IMpGIVzhsd0dbPYFRRxCA=.0d54605c-2d69-4a6e-8c9b-19f4f7a042e6@github.com>

On Wed, 19 May 2021 02:42:03 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>>       
>> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
>> -  x % -y  ==> [0, y - 1] RCE
>> -  x % y   ==> [0, y - 1] RCE
>> -  -x % y  ==> [-y + 1, 0]
>> -  -x % -y ==> [-y + 1, 0]
>> 
>> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
>> 
>> 
>> for(int i=0;i<1000;i++){
>>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>>   ....
>> }
>> 
>> 
>> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
>> 
>> Testing:
>> - test/hotspot/jtreg/compiler/c1/(slowdebug)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing whitespace; more comment

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4083

From stuefe at openjdk.java.net  Wed May 19 08:38:47 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 08:38:47 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long
Message-ID: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>

More than half of the total runtime of the gtests is currently used by just three tests:

- VirtualSpace.os_reserve_space_concurrent_vm
- VirtualSpace.os_virtual_space_concurrent_vm
- os_linux.reserve_memory_special_concurrent_vm

These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.

Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.

---

The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.

-------------

Commit messages:
 - start

Changes: https://git.openjdk.java.net/jdk/pull/4110/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4110&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267371
  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4110.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4110/head:pull/4110

PR: https://git.openjdk.java.net/jdk/pull/4110

From neliasso at openjdk.java.net  Wed May 19 08:46:43 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 19 May 2021 08:46:43 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
Message-ID: <oGuj8EzLk3QL97kmgg3NjpV4KtDC292viH-m7RFgHrE=.c6c3a88b-7ede-49b6-a225-797a4be05546@github.com>

On Tue, 18 May 2021 00:18:08 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove scratch register from vpmulld

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3806

From iwalulya at openjdk.java.net  Wed May 19 08:54:49 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 19 May 2021 08:54:49 GMT
Subject: RFR: 8267133:
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails with Not expected
 phases: RestorePreservedMarks, RemoveSelfForwardingPtr: expected true,
 was false
In-Reply-To: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
References: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
Message-ID: <v5z6j5HKrS8BljQafJx3laAyzJJzOakkhEwmfQj1-94=.3323ac51-474d-41aa-bdef-1e0a308b8bfc@github.com>

On Mon, 17 May 2021 11:57:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> `RestorePreservedMarks`, and `RemoveSelfForwardingPtr` are conditionally emitted (only on evac failure). Updating the test to exclude these events in the assert.
> 
> 
> double G1GCPhaseTimes::print_post_evacuate_collection_set() const {
>   ...
>   debug_phase(_gc_par_phases[RecalculateUsed], 1);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RemoveSelfForwardingPtr], 1);
>   }
> 
>   debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RecalculateUsed], 1);
>     debug_phase(_gc_par_phases[RestorePreservedMarks], 1);
>   }
>   ...
> }
> 
> 
> Tested: manually set a smaller heap size to see the test fail, but pass with the PR.

Marked as reviewed by iwalulya (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4056

From yyang at openjdk.java.net  Wed May 19 08:55:44 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 19 May 2021 08:55:44 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator if divisor
 is IntConstant [v3]
In-Reply-To: <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
Message-ID: <bzkP-2XRBw0V2x6jvGjh4pNTIouN6TOoxv0ehJ9fn6w=.ced79c97-b8a2-465c-94fd-a0ee04a5d023@github.com>

On Wed, 19 May 2021 02:42:03 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>>       
>> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
>> -  x % -y  ==> [0, y - 1] RCE
>> -  x % y   ==> [0, y - 1] RCE
>> -  -x % y  ==> [-y + 1, 0]
>> -  -x % -y ==> [-y + 1, 0]
>> 
>> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
>> 
>> 
>> for(int i=0;i<1000;i++){
>>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>>   ....
>> }
>> 
>> 
>> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
>> 
>> Testing:
>> - test/hotspot/jtreg/compiler/c1/(slowdebug)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing whitespace; more comment

Thank you Nils and Tobias for taking the time to review this patch! I've filed https://bugs.openjdk.java.net/browse/JDK-8267376 for investigating if it's possible to apply C2 RCE for % operator when divisor != 0.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4083

From alanb at openjdk.java.net  Wed May 19 09:03:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 19 May 2021 09:03:43 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <cwQrJqXGscoP-cf3HWcWTwW_nGiebz0p_UdgFip7Ed4=.1eb4cad1-7808-46dd-9b2c-96e15b4b35a5@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
 <cwQrJqXGscoP-cf3HWcWTwW_nGiebz0p_UdgFip7Ed4=.1eb4cad1-7808-46dd-9b2c-96e15b4b35a5@github.com>
Message-ID: <f2x_xRHhbblGhqxp3I16FrybMdtRQPXDn7PJdaQ-dXk=.c8b80bd2-d2c8-41a0-ae6e-5750b09706da@github.com>

On Wed, 19 May 2021 07:50:55 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I wonder if there needs to be one event per finalized object?
> 
> Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great.
> 
> Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do.

So some statistics or periodic event that N instances of class C were registered or queued? I think you are right that this would be a lot more valuable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From shade at openjdk.java.net  Wed May 19 09:07:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 19 May 2021 09:07:41 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long
In-Reply-To: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
Message-ID: <y0F4A4SEcVs3FlkZ7AW11txyIjyLGxfzrhh4KwtcJB8=.a5aa9bb2-e3c2-4f72-8aea-fdd769625e70@github.com>

On Wed, 19 May 2021 08:30:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> More than half of the total runtime of the gtests is currently used by just three tests:
> 
> - VirtualSpace.os_reserve_space_concurrent_vm
> - VirtualSpace.os_virtual_space_concurrent_vm
> - os_linux.reserve_memory_special_concurrent_vm
> 
> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
> 
> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
> 
> ---
> 
> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.

This looks good to me. I was kinda wondering the last time I looked at that test if 30 threads is excessive for the test as well.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4110

From yyang at openjdk.java.net  Wed May 19 09:08:48 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 19 May 2021 09:08:48 GMT
Subject: Integrated: 8267239: C1: RangeCheckElimination for % operator if
 divisor is IntConstant
In-Reply-To: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
Message-ID: <PqW9hdoURPB4RBEp5wz33l1k9K1iTOzero4K6wDclYw=.eb1e3e5c-5a6e-421c-894e-76b5ee555f81@github.com>

On Tue, 18 May 2021 08:20:09 GMT, Yi Yang <yyang at openjdk.org> wrote:

> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>       
> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
> -  x % -y  ==> [0, y - 1] RCE
> -  x % y   ==> [0, y - 1] RCE
> -  -x % y  ==> [-y + 1, 0]
> -  -x % -y ==> [-y + 1, 0]
> 
> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
> 
> 
> for(int i=0;i<1000;i++){
>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>   ....
> }
> 
> 
> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
> 
> Testing:
> - test/hotspot/jtreg/compiler/c1/(slowdebug)

This pull request has now been integrated.

Changeset: 0cf7e578
Author:    Yi Yang <yyang at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0cf7e5784b4ddb70c8674a814527d3e0c315a1ec
Stats:     109 lines in 3 files changed: 99 ins; 10 del; 0 mod

8267239: C1: RangeCheckElimination for % operator if divisor is IntConstant

Reviewed-by: thartmann, neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/4083

From chegar at openjdk.java.net  Wed May 19 09:14:39 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 19 May 2021 09:14:39 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
Message-ID: <u-c-gocw2FUcpDgVGhKLHzBmkFrS5uLuSgG4eNFqWV4=.dcbf1489-ce5a-4e4b-ab93-97a879797e27@github.com>

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

My 0.02$ ;-)  I really like the idea of a jdk.FinalizationStatistics event. The devil is (as always) in the details.

Multiple concerns have been raised above, which benefit from being separated out:

1) Raising an event per invocation of each individual finalizer may be costly when JFR is enabled (since there could be an extremely large number of these), as well as a little unwieldy for a human observer. Aggregating invocations of finalizers and reporting periodically seems like a nice solution to this.

2) A jdk.FinalizationStatistics event that provides an aggregate count of *all* finalizer invocations seems most straightforward, but less useful. A jdk.FinalizationStatistics event that provides per-class invocation metrics seems more useful, but at the expense of a more complex event structure. Maybe model jdk.FinalizationStatistics as a tuple of Class and long (count) - periodically committing multiple jdk.FinalizationStatistics events, one event per class? ( or was the thought to somehow aggregate all these per-class metrics into a single jdk.FinalizationStatistics event? )

3) If we keep the currently proposed semantic - capturing actual invocation/queueing counts (rather than registrations), then I see no reason why the implementation of a jdk.FinalizationStatistics needs to be in the JVM. The metrics can be captured in Java code and reported in a similar way to the container metrics (being proposed in [PR 3126][PR3126]). Surely, this would be more straightforward to implement and maintain, no?

4) The startup cost of JFR. I dunno enough about this, but what I do know is that a handler needs to be spun per Java-event, so maybe this has some bearing on the decision of no.3 above?

[PR3126]: https://github.com/openjdk/jdk/pull/3126

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From boris.ulasevich at bell-sw.com  Wed May 19 09:20:23 2021
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 19 May 2021 12:20:23 +0300
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
Message-ID: <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>

Hi Chris,

I agree that the problem is in C1_MacroAssembler::lock_object.

What I do not like in your fix is
- an arbitrary non-zero value is put into disp_hdr address for 'ne' case.
- there is a similar code pattern in 
SharedRuntime::generate_native_wrapper - should not it be fixed too?
- the second comment in hdr bits manipulation code is wrong: "// -2- 
test (hdr - SP) if the low two bits are 0"

regards,
Boris

On 19.05.2021 08:31, Chris Cole wrote:
> Hi All,
>
> I have continued to further investigate this bug that I reported and
> have some additional information.
>
> I believe that this issue is similar to JDK-8153107  "enabling
> ObjectSynchronizer::quick_enter() on ARM64 causes hangs" (see [1]),
> this impacted C2 on both ARM32 and ARM64. The fix for that issue (see
> [2]) fixed MacroAssembler::fast_lock() that is used by C2. When this
> fix was made, I believe only C2 was using
> ObjectSynchronizer::quick_enter(). Now (version 11.0.10+ and 15+) that
> C1 is using ObjectSynchronizer::quick_enter() due to JDK-8241234, a
> similar change to C1_MacroAssembler::lock_object() used by C1 is
> required. The following change to unconditionally store to the
> displaced header field should fix things for C1.
>
> diff --git a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> index 9d5c82dceb9..9a628eb7de5 100644
> --- a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> +++ b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> @@ -235,7 +235,8 @@ int C1_MacroAssembler::lock_object(Register hdr,
> Register obj,
>     sub(tmp2, hdr, SP, eq);
>     movs(tmp2, AsmOperand(tmp2, lsr, exact_log2(os::vm_page_size())), eq);
>     // If 'eq' then OK for recursive fast locking: store 0 into a lock record.
> -  str(tmp2, Address(disp_hdr, mark_offset), eq);
> +  // set to non zero otherwise (see discussion in JDK-8267042)
> +  str(tmp2, Address(disp_hdr, mark_offset));
>     b(fast_lock_done, eq);
>     // else need slow case
>     b(slow_case);
>
> This should fix the specific issue that I was seeing and that is
> reproduce with test case I provided.
>
> I also reviewed the code to see if there were any other possible issue
> related to Runtime1::monitorenter() not always initializing displaced
> header field due to ObjectSynchronizer::quick_enter(). I found that if
> the -XX:-UseFastLocking develop flag is used (C1 doesn't use any
> inline monitor lock/unlock code and just calls the
> Runtime1::monitorenter() and Runtime1::monitorexit()), then the test
> case will reproduce deadlock on any of the platforms (arm32, aarch64,
> x86_64, etc) due to uninitialized displaced header field. Here is a
> fix for that. (Note that this change below, makes the change above to
> c1_MacroAssembler_arm.cpp unnecessary).
>
> diff --git a/src/hotspot/share/runtime/synchronizer.cpp
> b/src/hotspot/share/runtime/synchronizer.cpp
> index 98afe838c49..db3eb255778 100644
> --- a/src/hotspot/share/runtime/synchronizer.cpp
> +++ b/src/hotspot/share/runtime/synchronizer.cpp
> @@ -355,11 +355,6 @@ bool ObjectSynchronizer::quick_enter(oop obj, Thread* self,
>       // Case: light contention possibly amenable to TLE
>       // Case: TLE inimical operations such as nested/recursive synchronization
>
> -    if (owner == self) {
> -      m->_recursions++;
> -      return true;
> -    }
> -
>       // This Java Monitor is inflated so obj's header will never be
>       // displaced to this thread's BasicLock. Make the displaced header
>       // non-NULL so this BasicLock is not seen as recursive nor as
> @@ -372,6 +367,11 @@ bool ObjectSynchronizer::quick_enter(oop obj, Thread* self,
>       // and last are the inflated Java Monitor (ObjectMonitor) checks.
>       lock->set_displaced_header(markWord::unused_mark());
>
> +    if (owner == self) {
> +      m->_recursions++;
> +      return true;
> +    }
> +
>       if (owner == NULL && m->try_set_owner_from(NULL, self) == NULL) {
>         assert(m->_recursions == 0, "invariant");
>         return true;
>
> I am also reviewing the biased_locking_enter() call from
> C1_MacroAssembler::lock_object(), this code path can call
> Runtime1::monitorenter() without initializing the displaced header
> field. But in this code path it might not be possible for
> ObjectSynchronizer::quick_enter() to return "true" without calling
> lock->set_displaced_header(markWord::unused_mark()), this would
> require current thread to own inflated monitor which seems to not be
> possible in this case when biased_locking_enter() is calling
> Runtime1::monitorenter().
>
> Anyway, I will continue to review the code to make sure this aren't
> any other issues related to this issue.
>
> Thanks,
> Chris
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8153107
> [2] http://hg.openjdk.java.net/jdk/jdk/rev/3e66d204af9b
>
> On Wed, May 12, 2021 at 8:58 PM Chris Cole <chris at sageembedded.com> wrote:
>> Hi Dan,
>>
>> Great, thanks! Feel free to contact me if there is anything else I can
>> do that is helpful.
>>
>> Chris
>>
>> On Wed, May 12, 2021 at 10:21 AM <daniel.daugherty at oracle.com> wrote:
>>> Hi Chris,
>>>
>>> I filed the following new bug on your behalf:
>>>
>>> JDK-8267042 bug in monitor locking/unlocking on ARM32 C1 due to
>>> uninitialized BasicObjectLock::_displaced_header
>>> https://bugs.openjdk.java.net/browse/JDK-8267042
>>>
>>> Dan
>>>
>>>
>>> On 5/12/21 1:02 PM, Chris Cole wrote:
>>>> Hi,
>>>>
>>>> Not sure if this is the appropriate place or method to report an OpenJDK
>>>> bug, if not please advise.
>>>>
>>>> I have discovered a bug with ARM32 C1 monitor locking/unlocking that can
>>>> result in deadlock. The bug was introduced with JCK-8241234 "Unify monitor
>>>> enter/exit runtime entries" [1]. This change introduced a call to
>>>> ObjectSynchronizer::quick_entry() within the logic for
>>>> Runtime1::monitorenter().
>>>> If the monitor is inflated and already owned by the current thread, then
>>>> ObjectSynchronizer::quick_entry() simply increments
>>>> ObjectMonitor::_recursions and returns. In this case
>>>> Runtime1::monitorenter() returns to the JIT compiled code without calling
>>>> "lock->set_displaced_header(markWord::unused_mark())" (see [2]). For ARM32
>>>> the _displaced_header field is not always initialized in JIT code before
>>>> calling Runtime1::monitorenter() helper. If the uninitialized value of
>>>> _displaced_header field on stack happens to be NULL, this causes an issue
>>>> because the JIT code to exit the monitor first checks for a NULL
>>>> _displaced_header as an indication for non-inflated recursive locking which
>>>> is a noop for exiting the monitor (see [3]). This means that the
>>>> Runtime1::monitorexit() helper is not called as required to exit this
>>>> inflated monitor, and the ObjectMonitor::_recursions is not decremented as
>>>> required. This leads to thread not unlocking the monitor when required and
>>>> deadlock when another thread tries to lock the monitor.
>>>>
>>>> This bug is not present on AArch64 and x86, because the displaced header is
>>>> initialized in JIT code with the "unlocked object header" value (which is
>>>> non-zero) before calling Runtime1::monitorenter() helper (see [4] and [5]).
>>>> Note sure about other CPU architectures.
>>>>
>>>> I see two ways to fix this.
>>>> 1) In ObjectSynchronizer::quick_entry() move the
>>>> "lock->set_displaced_header(markWord::unused_mark())" statement to before
>>>> the "if (owner == current)" at line 340 in share/runtime/synchronizer.cpp
>>>> (see [6]), so that Runtime1::monitorenter() helper logic always initializes
>>>> the displaced header field as was the case before JCK-8241234.
>>>> 2) For ARM32 add JIT code to initialize the displaced header field before
>>>> calling Runtime1::monitorenter() helper as done for AArch64 and x86.
>>>>
>>>> Not sure which is better (or maybe both are required for some reason I am
>>>> not aware of). I believe this "displacted header" on the stack can be
>>>> looked at by stack walkers but I am not familiar with the exact details and
>>>> if there are implications on this fix.
>>>>
>>>> The bug is also present in OpenJDK 11.0.10 and later (introduced by the
>>>> backport of JDK-8241234 [1]).
>>>>
>>>> I/my company (Sage Embedded Software) has signed the Oracle Contributor
>>>> Agreement (OCA) and have been granted access to JCK.
>>>>
>>>> The bug can be reproduced in my environment with the OpenJDK Community TCK
>>>> testing of java.io.PipedReader that deadlocks, but because reproduction of
>>>> the issue requires uninitialized stack field to be zero, it might not
>>>> happen in some environments. I have a Java test case that can reproduce
>>>> this issue on ARM in 32 bit mode. It is pasted inline below at the end of
>>>> the email. There is a "getZeroOnStack()" method that I think helps get a
>>>> zero into the uninitialized _displaced_header field. The test case source
>>>> code is copied from OpenJDK java.io.PipedReader source code and then
>>>> modified. It needs to be run with only C1 enabled (I am using minimal
>>>> variant to enforce this) and the following command line options
>>>> (-XX:-BackgroundCompilation -XX:CompileThreshold=500
>>>> -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"). The test
>>>> case should run and then end with "Source thread done" and "Reading
>>>> complete" output if the bug is not reproduced. If the monitor bug is
>>>> reproduced the test case will not exit and the main thread will be
>>>> deadlocked, with the main thread last printing "read() before wait" and
>>>> missing "read() after wait" and "Reading complete". If useful I can provide
>>>> the output of this test cause including -XX:PrintAssebly and logging that I
>>>> added to ObjectSynchronizer::quick_entry() that shows uninitialized
>>>> lock->_displaced_header and ObjectMonitor->_recursions continue to get
>>>> incremented (into the 1000s) as the MonitorBugTest.receive() method is
>>>> called in a loop.
>>>>
>>>> Please let me know if there is anything else that would be helpful. I hope
>>>> to become active in the OpenJDK Community. My time is a little limited at
>>>> the moment, so sometimes it might take a day to respond (I have 3 and 6
>>>> year old kids). In the coming years I expect to have additional time to be
>>>> more involved in the OpenJDK Community.
>>>>
>>>> Best regards,
>>>> Chris Cole
>>>> Sage Embedded Software LLC
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8241234
>>>> [2]
>>>> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L343
>>>> [3]
>>>> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L130
>>>> [4]
>>>> https://github.com/openjdk/jdk/blob/71b8ad45b4de6836e3bb2716ebf136f3f8ea2198/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp#L95
>>>> [5]
>>>> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74
>>>> [6]
>>>> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/share/runtime/synchronizer.cpp#L340
>>>>
>>>> /*
>>>>    * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights
>>>> reserved.
>>>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>    *
>>>>    * This code is free software; you can redistribute it and/or modify it
>>>>    * under the terms of the GNU General Public License version 2 only, as
>>>>    * published by the Free Software Foundation.  Oracle designates this
>>>>    * particular file as subject to the "Classpath" exception as provided
>>>>    * by Oracle in the LICENSE file that accompanied this code.
>>>>    *
>>>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>    * version 2 for more details (a copy is included in the LICENSE file that
>>>>    * accompanied this code).
>>>>    *
>>>>    * You should have received a copy of the GNU General Public License version
>>>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>    *
>>>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>>>    * or visit www.oracle.com if you need additional information or have any
>>>>    * questions.
>>>>    */
>>>>
>>>> package com.sageembedded.test;
>>>>
>>>> import java.io.IOException;
>>>> import java.io.InterruptedIOException;
>>>>
>>>> /*
>>>>    * java -cp bin -minimal -XX:-BackgroundCompilation -XX:CompileThreshold=500
>>>>    *  -XX:CompileOnly="com.sageembedded.test.MonitorBugTest::receive"
>>>>    *  -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
>>>>    *  com.sageembedded.test.MonitorBugTest
>>>>    */
>>>> public class MonitorBugTest {
>>>>
>>>>           private static int DATA_SIZE = 1000;
>>>>           private static int BUFFER_SIZE = 256;
>>>>
>>>>           private char buffer[] = new char[BUFFER_SIZE];
>>>>           private int writeIndex = -1;
>>>>           private int readIndex = 0;
>>>>
>>>>           public Object lock = new Object();
>>>>
>>>>           public static void main(String[] args) {
>>>>                   MonitorBugTest test = new MonitorBugTest();
>>>>                   test.run();
>>>>           }
>>>>           private void run() {
>>>>                   System.out.println("Starting test");
>>>>
>>>>                   SourceThread source = new SourceThread();
>>>>                   source.start();
>>>>
>>>>                   try {
>>>>                           for (int i = 0; i < DATA_SIZE; i++) {
>>>>                                   read();
>>>>                           }
>>>>                   } catch (IOException e) {
>>>>                           e.printStackTrace();
>>>>                   }
>>>>                   System.out.println("Reading complete");
>>>>
>>>>           }
>>>>
>>>>           synchronized void receive(char data[], int offset, int length)
>>>> throws IOException {
>>>>                   while (--length >= 0) {
>>>>                           getZeroOnStack(offset);
>>>>                           receive(data[offset++]);
>>>>                   }
>>>>           }
>>>>
>>>>           private void getZeroOnStack(int offset) {
>>>>                   int l1;
>>>>                   int l2;
>>>>                   int l3;
>>>>                   int l4;
>>>>                   int l5;
>>>>                   int l6;
>>>>                   int l7;
>>>>                   int l8;
>>>>                   int l9;
>>>>                   int l10;
>>>>                   int l11;
>>>>                   int l12;
>>>>                   int l13;
>>>>                   int l14;
>>>>                   int l15;
>>>>                   int l16;
>>>>
>>>>                   l1 = 0;
>>>>                   l2 = 0;
>>>>                   l3 = 0;
>>>>                   l4 = 0;
>>>>                   l5 = 0;
>>>>                   l6 = 0;
>>>>                   l7 = 0;
>>>>                   l8 = 0;
>>>>                   l9 = 0;
>>>>                   l10 = 0;
>>>>                   l11 = 0;
>>>>                   l12 = 0;
>>>>                   l13 = 0;
>>>>                   l14 = 0;
>>>>                   l15 = 0;
>>>>                   l16 = 0;
>>>>           }
>>>>
>>>>           synchronized void receive(int c) throws IOException {
>>>>                   while (writeIndex == readIndex) {
>>>>                           notifyAll();
>>>>                           try {
>>>>                                   wait(1000);
>>>>                           } catch (InterruptedException e) {
>>>>                                   throw new InterruptedIOException();
>>>>                           }
>>>>                   }
>>>>                   if (writeIndex < 0) {
>>>>                           writeIndex = 0;
>>>>                           readIndex = 0;
>>>>                   }
>>>>                   buffer[writeIndex++] = (char) c;
>>>>                   if (writeIndex >= buffer.length) {
>>>>                           writeIndex = 0;
>>>>                   }
>>>>           }
>>>>
>>>>           synchronized void last() {
>>>>                   notifyAll();
>>>>           }
>>>>           public synchronized int read() throws IOException {
>>>>                   while (writeIndex < 0) {
>>>>                           notifyAll();
>>>>                           try {
>>>>                                   System.out.println("read() before wait");
>>>>                                   wait(1000);
>>>>                                   System.out.println("read() after wait");
>>>>                           } catch (InterruptedException e) {
>>>>                                   throw new InterruptedIOException();
>>>>                           }
>>>>                   }
>>>>                   int value = buffer[readIndex++];
>>>>                   if (readIndex >= buffer.length) {
>>>>                           readIndex = 0;
>>>>                   }
>>>>                   if (writeIndex == readIndex) {
>>>>                           writeIndex = -1;
>>>>                   }
>>>>                   return value;
>>>>           }
>>>>
>>>>           private class SourceThread extends Thread {
>>>>                   @Override
>>>>                   public void run() {
>>>>                           System.out.println("Source thread start");
>>>>                           char data[] = new char[DATA_SIZE];
>>>>                           try {
>>>>                                   receive(data, 0, data.length);
>>>>                                   last();
>>>>                           } catch (IOException e) {
>>>>                                   e.printStackTrace();
>>>>                           }
>>>>                           System.out.println("Source thread done");
>>>>                   }
>>>>           }
>>>> }


From stuefe at openjdk.java.net  Wed May 19 09:30:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 09:30:40 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long
In-Reply-To: <y0F4A4SEcVs3FlkZ7AW11txyIjyLGxfzrhh4KwtcJB8=.a5aa9bb2-e3c2-4f72-8aea-fdd769625e70@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <y0F4A4SEcVs3FlkZ7AW11txyIjyLGxfzrhh4KwtcJB8=.a5aa9bb2-e3c2-4f72-8aea-fdd769625e70@github.com>
Message-ID: <BPDeDDb05h-spDSg7WCmdATIuKcGu95szxDXM6Tngx8=.1d7eee2b-02c6-40a5-a592-b0b9b960dfee@github.com>

On Wed, 19 May 2021 09:04:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This looks good to me. I was kinda wondering the last time I looked at that test if 30 threads is excessive for the test as well.

I'm honestly not sure why these tests are run concurrently; it looks to me like there is no VM internal synchronization involved which we could test, this is basically just a bunch of parallel mmap()s. I may miss something here.

Had been introduced (as jtreg-started whitebox test) with https://bugs.openjdk.java.net/browse/JDK-8027237. The associated RFR thread does not discuss the run parameters.

@stefank Stefan, do you think we could reduce the number of Threads for these tests too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From stefank at openjdk.java.net  Wed May 19 09:58:47 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 19 May 2021 09:58:47 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long
In-Reply-To: <BPDeDDb05h-spDSg7WCmdATIuKcGu95szxDXM6Tngx8=.1d7eee2b-02c6-40a5-a592-b0b9b960dfee@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <y0F4A4SEcVs3FlkZ7AW11txyIjyLGxfzrhh4KwtcJB8=.a5aa9bb2-e3c2-4f72-8aea-fdd769625e70@github.com>
 <BPDeDDb05h-spDSg7WCmdATIuKcGu95szxDXM6Tngx8=.1d7eee2b-02c6-40a5-a592-b0b9b960dfee@github.com>
Message-ID: <SKY_YEHQhXLpPOJkLs8U7LpWogENvvV5rbjQzRq7Hn0=.6bff8d27-7aa0-4eb5-aa58-7a2eb137719c@github.com>

On Wed, 19 May 2021 09:27:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This looks good to me. I was kinda wondering the last time I looked at that test if 30 threads is excessive for the test as well.
>
>> This looks good to me. I was kinda wondering the last time I looked at that test if 30 threads is excessive for the test as well.
> 
> I'm honestly not sure why these tests are run concurrently; it looks to me like there is no VM internal synchronization involved which we could test, this is basically just a bunch of parallel mmap()s. I may miss something here.
> 
> Had been introduced (as jtreg-started whitebox test) with https://bugs.openjdk.java.net/browse/JDK-8027237. The associated RFR thread does not discuss the run parameters.
> 
> @stefank Stefan, do you think we could reduce the number of Threads for these tests too?

@tstuefe Do whatever you think is appropriate for this test. I'm not particularly fond of having stress tests in our gtest suite, and would have preferred to not have them here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From ayang at openjdk.java.net  Wed May 19 11:32:47 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 May 2021 11:32:47 GMT
Subject: Integrated: 8267133:
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails with Not expected
 phases: RestorePreservedMarks, RemoveSelfForwardingPtr: expected true,
 was false
In-Reply-To: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
References: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
Message-ID: <NcaE08hYOLLMoYdbCXZRUtgvUVi5SZ2bOdcq80N4zR0=.8a5a3eea-4d10-4bb9-9d84-e5071894c0dc@github.com>

On Mon, 17 May 2021 11:57:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> `RestorePreservedMarks`, and `RemoveSelfForwardingPtr` are conditionally emitted (only on evac failure). Updating the test to exclude these events in the assert.
> 
> 
> double G1GCPhaseTimes::print_post_evacuate_collection_set() const {
>   ...
>   debug_phase(_gc_par_phases[RecalculateUsed], 1);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RemoveSelfForwardingPtr], 1);
>   }
> 
>   debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RecalculateUsed], 1);
>     debug_phase(_gc_par_phases[RestorePreservedMarks], 1);
>   }
>   ...
> }
> 
> 
> Tested: manually set a smaller heap size to see the test fail, but pass with the PR.

This pull request has now been integrated.

Changeset: 1b93b812
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1b93b81270770c208efc8c9bb10bb460636008b7
Stats:     7 lines in 2 files changed: 4 ins; 3 del; 0 mod

8267133: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails with Not expected phases: RestorePreservedMarks, RemoveSelfForwardingPtr: expected true, was false
8267218: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails with Not found phases\: StringDedupQueueFixup, StringDedupTableFixup

Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Reviewed-by: tschatzl, iwalulya

-------------

PR: https://git.openjdk.java.net/jdk/pull/4056

From ayang at openjdk.java.net  Wed May 19 11:32:46 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 May 2021 11:32:46 GMT
Subject: RFR: 8267133:
 jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails with Not expected
 phases: RestorePreservedMarks, RemoveSelfForwardingPtr: expected true,
 was false
In-Reply-To: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
References: <W3Setr-3e7uhSPpvXRwvcFY7K3teSQzDdh45fsd3PTs=.05b29982-1cf5-48c9-9056-75d075701372@github.com>
Message-ID: <wGlFv0sCZaj5goXZHFmO_LUzQ7UJUqmLyZfTfEtr8DA=.9db4d984-8174-42b0-95a4-e0d7ef29c806@github.com>

On Mon, 17 May 2021 11:57:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> `RestorePreservedMarks`, and `RemoveSelfForwardingPtr` are conditionally emitted (only on evac failure). Updating the test to exclude these events in the assert.
> 
> 
> double G1GCPhaseTimes::print_post_evacuate_collection_set() const {
>   ...
>   debug_phase(_gc_par_phases[RecalculateUsed], 1);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RemoveSelfForwardingPtr], 1);
>   }
> 
>   debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
>   if (G1CollectedHeap::heap()->evacuation_failed()) {
>     debug_phase(_gc_par_phases[RecalculateUsed], 1);
>     debug_phase(_gc_par_phases[RestorePreservedMarks], 1);
>   }
>   ...
> }
> 
> 
> Tested: manually set a smaller heap size to see the test fail, but pass with the PR.

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4056

From github.com+4146708+a74nh at openjdk.java.net  Wed May 19 11:48:39 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Wed, 19 May 2021 11:48:39 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v2]
In-Reply-To: <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
Message-ID: <JejOaHtyrGomCHPfJYQIuPEIrbrhMAH87qseIhjeIqw=.ba337013-dd39-477f-8dd1-e602d081d7f2@github.com>

On Tue, 18 May 2021 10:03:50 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add pauth assert to bsd signal handler
>    
>    I could also add the same to windows, but the pauth functions are
>    currently blank for windows.
>    
>    Change-Id: I1093c576ea2e9a94d0d76176d69d28fc2e5e29c1
>  - Split pauth_aarch64.hpp into os_cpu variants
>    
>    Change-Id: Ib39f42e0ed09156b2fc861117f304ef565c25f93

Any outstanding issues with this?
* The patch fixes issues on Linux distros with PAC support.
* Changes will help Apple arm64e, but there are additional issues that need fixing in a future PR.
* No changes to windows port (all new functions do nothing). If PAC is added to windows, the functions will need filling out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From ddong at openjdk.java.net  Wed May 19 12:01:42 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 19 May 2021 12:01:42 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8]
In-Reply-To: <NhKkwi45lMXHi2gdP6xS84ZWrdun0RARI7hDM1oH7gk=.ea09d215-6cb1-44c8-a7be-04aaba7f4b4a@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <NVEFWwB0Vn6aYKTzjqj6USyZn6D0QXcbjVFsvJr1_4c=.6b6f6377-993d-44e9-bb3e-1c945bc5ec2f@github.com>
 <gn4ESeR60R5GQtWDWKwyFZqbx-4uxMi-Kh__UhF34vY=.8d238da2-f494-4841-9985-1529b48eb836@github.com>
 <xju5HnlXfwTqKiQJg0yoXko0le3cQB1higMnxVPn7uk=.9d93adf3-6b7f-440e-94e7-084880674dc7@github.com>
 <NhKkwi45lMXHi2gdP6xS84ZWrdun0RARI7hDM1oH7gk=.ea09d215-6cb1-44c8-a7be-04aaba7f4b4a@github.com>
Message-ID: <PHypczaKN2wPjnf8jFOQkROV4VDaJMie5Of4VPSMsK4=.9ea2458d-4283-40ad-a675-ecff69bf1ffd@github.com>

On Tue, 18 May 2021 08:37:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hi,
>> I think it makes sense.
>> How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch?
>
> I created a CR for this:
> https://bugs.openjdk.java.net/browse/JDK-8267303
> 
> but I still think that this usage should not be introduced in this patch.

@stefank 
Could you review it again?

Thanks,
Denghui

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From mcimadamore at openjdk.java.net  Wed May 19 12:15:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 19 May 2021 12:15:28 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v23]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <G5FZbzEIoJwKU0kUDXast1TMqu4zoJWRkwRtUDg-JZQ=.9868d49d-ea32-40c6-9683-cd2682958eeb@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix VaList test
  Remove unused code in Utils

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f6051daf..f5668ffc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21-22

  Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From shade at openjdk.java.net  Wed May 19 12:40:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 19 May 2021 12:40:12 GMT
Subject: RFR: 8267396: Avoid recording "pc" in unhandled oops detector for
 better performance
Message-ID: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>

See the rationale in the bug.

Additional testing:
 - [x] Known slow test with `-XX:+CheckUnhandledOops`
 - [ ] tier1 with `-XX:+CheckUnhandledOops`

-------------

Commit messages:
 - 8267396: Avoid recording "pc" in unhandled oops detector for better performance

Changes: https://git.openjdk.java.net/jdk/pull/4114/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4114&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267396
  Stats: 11 lines in 3 files changed: 0 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4114.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4114/head:pull/4114

PR: https://git.openjdk.java.net/jdk/pull/4114

From vkempik at openjdk.java.net  Wed May 19 13:01:53 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Wed, 19 May 2021 13:01:53 GMT
Subject: RFR: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
Message-ID: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>

Please review this patch for call_VM_Base routine.
it's expected there the LR is callee-saved register, but it's not on aarch64.
when InterpreterRuntime::throw_pending_exception is tail-call optimized,
the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR.
It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build.

-------------

Commit messages:
 - JDK-8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash

Changes: https://git.openjdk.java.net/jdk/pull/4115/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4115&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267235
  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4115/head:pull/4115

PR: https://git.openjdk.java.net/jdk/pull/4115

From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From stefank at openjdk.java.net  Wed May 19 14:48:44 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 19 May 2021 14:48:44 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9]
In-Reply-To: <gWqimOho65l_cm0ub7jE2Op-ayWhXpRIsr7AoV3cHBM=.131f808f-fd6e-4d48-bfd6-b7b39047bf0a@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <gWqimOho65l_cm0ub7jE2Op-ayWhXpRIsr7AoV3cHBM=.131f808f-fd6e-4d48-bfd6-b7b39047bf0a@github.com>
Message-ID: <o9DXqyCTGegeMeMnaNMU4BF6fX-gZKht50LMo9u0Kwk=.e6b9d011-0a24-4e8c-a6f7-dda0ed489e9e@github.com>

On Tue, 18 May 2021 11:39:04 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remote LogMinObjAlignmentInBytes

The identity_hash() changes look good.

FWIW, some allocators return 16 byte aligned memory chunks, so shifting by 3 might leave a non-set LSB. Maybe when fixing JDK-8267303, we should also consider if the shift should be 3 or 4.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From stuefe at openjdk.java.net  Wed May 19 14:59:05 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 14:59:05 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
Message-ID: <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>

> More than half of the total runtime of the gtests is currently used by just three tests:
> 
> - VirtualSpace.os_reserve_space_concurrent_vm
> - VirtualSpace.os_virtual_space_concurrent_vm
> - os_linux.reserve_memory_special_concurrent_vm
> 
> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
> 
> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
> 
> ---
> 
> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  5 threads 3 secs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4110/files
  - new: https://git.openjdk.java.net/jdk/pull/4110/files/78e0c2c5..fd87020a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4110&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4110&range=00-01

  Stats: 8 lines in 3 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4110.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4110/head:pull/4110

PR: https://git.openjdk.java.net/jdk/pull/4110

From stuefe at openjdk.java.net  Wed May 19 14:59:05 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 14:59:05 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long
In-Reply-To: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
Message-ID: <sXSSDU15ePG3i0BHtpEVeAHBKqCRT6OR8pnF8CoWsDE=.ee380157-3977-491d-9db6-c92d65fedfef@github.com>

On Wed, 19 May 2021 08:30:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> More than half of the total runtime of the gtests is currently used by just three tests:
> 
> - VirtualSpace.os_reserve_space_concurrent_vm
> - VirtualSpace.os_virtual_space_concurrent_vm
> - os_linux.reserve_memory_special_concurrent_vm
> 
> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
> 
> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
> 
> ---
> 
> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.

Hi guys,

I am not convinced these tests make a lot of sense. I leave them in for now because they may be of use on AIX where we maintain global data structures and also possibly for stress-testing NMT (I work on JDK-8256844: "Make NMT late-initializable" which will make it possible to enable NMT in gtests, and thereby stress-testing NMT itself). Beyond that, they are just hitting mmap() without really testing VM infrastructure.

I disable `reserve_memory_special_concurrent` for non-large-page-runs. And I reduced the time to run further from 5 to 3 seconds, and the number of threads from 30 to 5.

Like @stefank I also think the gtests are the wrong place for these kind of tests. Jtreg tests are a better place for this, offering finer grained control and better thread facilities. I remember now we had this discussion when these tests were introduced (https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-March/049533.html).

Well, maybe we can do something about this in the future (split them out, remove them, move them back to jtreg...).

Thanks, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From ddong at openjdk.java.net  Wed May 19 15:14:43 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 19 May 2021 15:14:43 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9]
In-Reply-To: <o9DXqyCTGegeMeMnaNMU4BF6fX-gZKht50LMo9u0Kwk=.e6b9d011-0a24-4e8c-a6f7-dda0ed489e9e@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <gWqimOho65l_cm0ub7jE2Op-ayWhXpRIsr7AoV3cHBM=.131f808f-fd6e-4d48-bfd6-b7b39047bf0a@github.com>
 <o9DXqyCTGegeMeMnaNMU4BF6fX-gZKht50LMo9u0Kwk=.e6b9d011-0a24-4e8c-a6f7-dda0ed489e9e@github.com>
Message-ID: <NGh6BWcAWTYwyw0hCjv8zs77FXEVuVPPLULytsTWcg8=.a5e77520-fcb8-4eba-93f8-7dfa78436082@github.com>

On Wed, 19 May 2021 14:45:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The identity_hash() changes look good.
> 
> FWIW, some allocators return 16 byte aligned memory chunks, so shifting by 3 might leave a non-set LSB. Maybe when fixing JDK-8267303, we should also consider if the shift should be 3 or 4.

Thank you!

@iwanowww 
please help sponsor it if there is no other problem, thanks in advance : )

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From gziemski at openjdk.java.net  Wed May 19 15:31:39 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 19 May 2021 15:31:39 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v2]
In-Reply-To: <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
Message-ID: <sL17KDYLFhcxAM0lJGhxwuLbwbbM7Ke-p7Lkq5FNA2Y=.16565590-cd88-4be8-9883-dbcc5e27b2de@github.com>

On Tue, 18 May 2021 10:03:50 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add pauth assert to bsd signal handler
>    
>    I could also add the same to windows, but the pauth functions are
>    currently blank for windows.
>    
>    Change-Id: I1093c576ea2e9a94d0d76176d69d28fc2e5e29c1
>  - Split pauth_aarch64.hpp into os_cpu variants
>    
>    Change-Id: Ib39f42e0ed09156b2fc861117f304ef565c25f93

src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp line 42:

> 40: inline address pauth_strip_pointer(address ptr) {
> 41: #ifdef __APPLE__
> 42:   ptrauth_strip(ptr, ptrauth_key_asib);

Wouldn't it be safer to use the alias `ptrauth_key_process_dependent_code` instead of the underlaying primitive enum `ptrauth_key_asib`?

`  ptrauth_strip(ptr, ptrauth_key_process_dependent_code);`

Can you please elaborate on why this particular key was used, for example why not `ptrauth_key_process_independent_code`? There are so many other...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From shade at openjdk.java.net  Wed May 19 16:00:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 19 May 2021 16:00:51 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v3]
In-Reply-To: <OeK5Ff0cZaQ7qV2HFv8IsffVTbME9-ozEXSSu-gWsO8=.72593252-988a-478d-9360-51282530b8a6@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <OeK5Ff0cZaQ7qV2HFv8IsffVTbME9-ozEXSSu-gWsO8=.72593252-988a-478d-9360-51282530b8a6@github.com>
Message-ID: <ueyc5n-jOVWrJN5hY7hqoSPpHpiObOONrbUUzv1Gu3o=.4ef20859-6a28-4be1-a670-040739ae3941@github.com>

On Tue, 16 Feb 2021 10:26:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
>> 
>> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
>> 
>> For the forwardee load side, we need to guarantee "acquire". We do not do it now, reading the markword without memory semantics. It does not seem to pose a practical problem today, because GC does not access the object contents in the new copy, and mutators get this from the JRT-called stub that separates the fwdptr access and object contents access by a lot. It still should be cleaner to "acquire" the mark on load to avoid surprises.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `tier1` with Shenandoah
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - A few minor touchups
>  - Add a blurb to x86 code as well
>  - Use implicit "consume" in AArch64, add more notes.
>  - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
>  - Make sure to access fwdptr with acquire semantics in assembler code
>  - 8261492: Shenandoah: reconsider forwardee accesses memory ordering

Not yet, bot. Still waiting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2496

From github.com+4146708+a74nh at openjdk.java.net  Wed May 19 16:03:42 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Wed, 19 May 2021 16:03:42 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v2]
In-Reply-To: <sL17KDYLFhcxAM0lJGhxwuLbwbbM7Ke-p7Lkq5FNA2Y=.16565590-cd88-4be8-9883-dbcc5e27b2de@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
 <sL17KDYLFhcxAM0lJGhxwuLbwbbM7Ke-p7Lkq5FNA2Y=.16565590-cd88-4be8-9883-dbcc5e27b2de@github.com>
Message-ID: <7gEM1aNO-ZZEYc4p6en6PgcDoEjXe8lq-XYGSsTFl6c=.6df45640-716f-47f3-a251-2b3e775a62a4@github.com>

On Wed, 19 May 2021 15:27:22 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add pauth assert to bsd signal handler
>>    
>>    I could also add the same to windows, but the pauth functions are
>>    currently blank for windows.
>>    
>>    Change-Id: I1093c576ea2e9a94d0d76176d69d28fc2e5e29c1
>>  - Split pauth_aarch64.hpp into os_cpu variants
>>    
>>    Change-Id: Ib39f42e0ed09156b2fc861117f304ef565c25f93
>
> src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp line 42:
> 
>> 40: inline address pauth_strip_pointer(address ptr) {
>> 41: #ifdef __APPLE__
>> 42:   ptrauth_strip(ptr, ptrauth_key_asib);
> 
> Wouldn't it be safer to use the alias `ptrauth_key_process_dependent_code` instead of the underlaying primitive enum `ptrauth_key_asib`?
> 
> `  ptrauth_strip(ptr, ptrauth_key_process_dependent_code);`
> 
> Can you please elaborate on why this particular key was used, for example why not `ptrauth_key_process_independent_code`? There are so many other...

For the values being stripped in this patch, they will always be return addresses saved on the stack. My first choice here was ptrauth_key_return_address, but I wanted it to be a little more generic and:
ptrauth_key_return_address = ptrauth_key_process_dependent_code = ptrauth_key_asib [1]

For a strip function, the key shouldn't matter as xpaci/xaplri instructions work for both IA and IB keys. However when I've dumped my test binaries on mac, it looked like the compiler used generic bitmasking instead of the xpac instructions. So it's possible the relevant key does matter here. Using the IB key ensures ptrauth_strip() always does the stripping (according to ptrauth.h comments), which is probably the safest option for now. I suspect full mac arm64e support would eventually require having multiple strip functions (pauth_strip_retaddr(), pauth_strip_functptr(), etc)

[1] https://opensource.apple.com/source/xnu/xnu-4903.241.1/EXTERNAL_HEADERS/ptrauth.h.auto.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From gziemski at openjdk.java.net  Wed May 19 16:05:44 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 19 May 2021 16:05:44 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
Message-ID: <ZcxRaavoZDnSqt0hCvdnKOxeN2Dis7adygy140jD7e8=.7140d3cf-832b-4bc3-8cd3-ca9bcad0f9f9@github.com>

On Wed, 19 May 2021 14:59:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> More than half of the total runtime of the gtests is currently used by just three tests:
>> 
>> - VirtualSpace.os_reserve_space_concurrent_vm
>> - VirtualSpace.os_virtual_space_concurrent_vm
>> - os_linux.reserve_memory_special_concurrent_vm
>> 
>> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
>> 
>> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
>> 
>> ---
>> 
>> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5 threads 3 secs

Hi Thomas, you said `The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.`

Does that mean that the 30 second saving come from some of the tests being timed out? Why then bother at all with them?

It does sound like they should move out of tier1...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From duke at openjdk.java.net  Wed May 19 16:08:48 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 16:08:48 GMT
Subject: Withdrawn: 8259643: ZGC can return metaspace OOM prematurely
In-Reply-To: <V-_4hXiYrxvOCdZmmQuwz7zaHxMIZ6MlPg2fcdr2Y7M=.bb702064-3de5-4d56-a040-4883b9419bab@github.com>
References: <V-_4hXiYrxvOCdZmmQuwz7zaHxMIZ6MlPg2fcdr2Y7M=.bb702064-3de5-4d56-a040-4883b9419bab@github.com>
Message-ID: <vzFULMzsTyvEMMVY-MOTt_tuq3Ll_IIqKj2O98parG4=.7558ee99-3d31-48aa-bf80-6f58c144e19a@github.com>

On Thu, 28 Jan 2021 12:55:55 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> There exists a race condition for ZGC metaspace allocations, where an allocation can throw OOM due to unbounded starvation from other threads. Towards the end of the allocation dance, we conceptually do this:
> 
> 1. full_gc()
> 2. final_allocation_attempt()
> 
> And if we still fail at 2 after doing a full GC, we conclude that there isn't enough metaspace memory. However, if the thread gets preempted between 1 and 2, then an unbounded number of metaspace allocations from other threads can fill up the entire metaspace, making the final allocation attempt fail and hence throw. This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM. I managed to reproduce this with the right sleeps.
> 
> The way we deal with this particular issue for heap allocations, is to have an allocation request queue, and satisfy those allocations before others, preventing starvation. My solution to this metaspace OOM problem will be to basically do exactly that - have a queue of "critical" allocations, that get precedence over normal metaspace allocations.
> 
> The solution should work for other concurrent GCs (who likely have the same issue), but I only tried this with ZGC, so I am only hooking in ZGC to the new API (for concurrently unloading GCs to manage critical metaspace allocations) at this point.
> 
> Passes ZGC tests from tier 1-5, and the particular test that failed (with the JVM sleeps that make it fail deterministically).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2289

From duke at openjdk.java.net  Wed May 19 16:13:43 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 16:13:43 GMT
Subject: Withdrawn: 8247471: Enhance CPU load events with the actual elapsed
 CPU time
In-Reply-To: <euqeb7rdqr4HWxIku5uMMOB__7fZfvYES_7hd6rOYhQ=.2c47e9b2-f435-44e2-aca4-4b1b3a041b80@github.com>
References: <euqeb7rdqr4HWxIku5uMMOB__7fZfvYES_7hd6rOYhQ=.2c47e9b2-f435-44e2-aca4-4b1b3a041b80@github.com>
Message-ID: <_R9hfaG1p7348GmpQD7q9ro4UfZxQjRuIDC3uKYcFtg=.6dfe7825-a231-4e22-81d3-ca9902231122@github.com>

On Thu, 21 Jan 2021 17:34:58 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> A continuation of an RFR thread started last year - https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-June/001533.html
> 
> This change adds the raw CPU time value to CPU load events (per-thread and per-process as well). 
> The CPU time value is already known and used to calculate the load so adding it to the events does not incur any extra overhead while making it much easier for the end users to eg. aggregate and compare the active execution time per time period without the detailed knowledge how JFR computes and normalizes the CPU load.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2186

From sviswanathan at openjdk.java.net  Wed May 19 16:18:47 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 16:18:47 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v9]
In-Reply-To: <Afbme5vB7gOTEPxY52QIAncuksoolnlYVDAE0nvfvkQ=.b8e2a409-afe1-41ff-8403-4e18165b7b13@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <V5QI8QngT5kpjnphz4qa3zxJPElSeU5kXIp1_csCunY=.dcaf787d-d1cc-44ed-9e89-cf0c7f0391da@github.com>
 <4KqXJjwOAZfYQGe-guwozZskn8lf2RR7oTBu5aHSUQo=.ca01baa1-601b-4cab-b546-134173ce4ce9@github.com>
 <Afbme5vB7gOTEPxY52QIAncuksoolnlYVDAE0nvfvkQ=.b8e2a409-afe1-41ff-8403-4e18165b7b13@github.com>
Message-ID: <iINnO3wKx0LZ9SwasSYyE7uis2JQ_NGnRpG9TLrtuqk=.5e633862-5d3c-49e2-86f8-d8059ec6f52a@github.com>

On Mon, 17 May 2021 19:13:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I'm not a lawyer, but Pengfei, please contribute this benchmark. All you have to do is copy it into cr.openjdk.java.net. That should be enough for someone else to take it from there. And AFAICR files should have a copyright header, which you should do too.
>
>> I'm not a lawyer, but Pengfei, please contribute this benchmark. All you have to do is copy it into cr.openjdk.java.net. That should be enough for someone else to take it from there. And AFAICR files should have a copyright header, which you should do too.
> 
> @theRealAph  micro is already there for long time:  https://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java
> It missed copyright header which is added in these changes.

@vnkozlov Looks like automated tests are not run. Could you please help?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From stuefe at openjdk.java.net  Wed May 19 16:38:46 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 16:38:46 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <ZcxRaavoZDnSqt0hCvdnKOxeN2Dis7adygy140jD7e8=.7140d3cf-832b-4bc3-8cd3-ca9bcad0f9f9@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
 <ZcxRaavoZDnSqt0hCvdnKOxeN2Dis7adygy140jD7e8=.7140d3cf-832b-4bc3-8cd3-ca9bcad0f9f9@github.com>
Message-ID: <7X_st5Ne6BuTGj0rfcXU6KT_i1jRZDEt0BFEoH3eGLI=.260cf9c6-4452-4559-9bb3-f565e82d7933@github.com>

On Wed, 19 May 2021 16:03:09 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Hi Thomas, you said `The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.`
> 
> Does that mean that the 30 second saving come from some of the tests being timed out? Why then bother at all with them?
> 
> It does sound like they should move out of tier1...

Hi Gerard,

the test don't time out; they run a fixed amount of time. Sorry, "Timeout" was a bad phrasing here.

Moving them out of tier1 (or alternatively just getting rid of them) would be fine but as a separate RFE. The former would require either splitting gtests into several units, some tier1 worthy, some not; or to reimplement them as jtreg tests (as they had been before). Both is significantly more effort than I want to put into right now.

Thanks, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From duke at openjdk.java.net  Wed May 19 16:38:48 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 16:38:48 GMT
Subject: Withdrawn: 8256916: Add JFR event for OutOfMemoryError
In-Reply-To: <sG2KrNsiOuQA_oiwWoKTQAqzKV7Z10rhYtJLHChTRQg=.c2a3eaa0-cf04-4e74-9d2e-bedfd51053a6@github.com>
References: <sG2KrNsiOuQA_oiwWoKTQAqzKV7Z10rhYtJLHChTRQg=.c2a3eaa0-cf04-4e74-9d2e-bedfd51053a6@github.com>
Message-ID: <OtDLaKms0k_eiKTQLBj1FY6v98FUv88GaOG7-GBWMLw=.26dccff9-07a0-4ed1-9caa-b341f40fc2ca@github.com>

On Tue, 24 Nov 2020 04:31:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> OOM on Metaspace would be reported in `MetaspaceOOM` JFR event, however other OOM (e.g. Java heap) would not be reported.
> 
> It is useful if JFR reports OOMs.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1403

From egahlin at openjdk.java.net  Wed May 19 16:44:43 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 May 2021 16:44:43 GMT
Subject: RFR: 8247471: Enhance CPU load events with the actual elapsed CPU
 time
In-Reply-To: <euqeb7rdqr4HWxIku5uMMOB__7fZfvYES_7hd6rOYhQ=.2c47e9b2-f435-44e2-aca4-4b1b3a041b80@github.com>
References: <euqeb7rdqr4HWxIku5uMMOB__7fZfvYES_7hd6rOYhQ=.2c47e9b2-f435-44e2-aca4-4b1b3a041b80@github.com>
Message-ID: <BP0InTCve0vuerqIn1MzPlmxKc1kaasWo2CAGleuygA=.5931d974-0b8a-4c7a-ada2-e052d8e672fc@github.com>

On Thu, 21 Jan 2021 17:34:58 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> A continuation of an RFR thread started last year - https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-June/001533.html
> 
> This change adds the raw CPU time value to CPU load events (per-thread and per-process as well). 
> The CPU time value is already known and used to calculate the load so adding it to the events does not incur any extra overhead while making it much easier for the end users to eg. aggregate and compare the active execution time per time period without the detailed knowledge how JFR computes and normalizes the CPU load.

It would be nice to have this for JDK 17, but I guess we are stuck on how the elapsed difference should be reported.

I would like to avoid using the duration field, because it's not used for any other event that samples data periodically. We could be opening a can of worms.

If we are going to measure execution time since the last sample, I think we should make it clear in the description, i.e "Elapsed JVM User CPU Time since last sample". While not optimal, a separate field or duration, could be added in a later release, even though it could lead to bugs, if using JFR on an old release where duration is 0 s.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2186

From kvn at openjdk.java.net  Wed May 19 16:50:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 19 May 2021 16:50:51 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
Message-ID: <vR1xdDitjcgV48NFSMaoLv4IYzrWn47xfdangoQbhOM=.8ff4836f-a366-4f89-aa5e-c75e1969cba8@github.com>

On Tue, 18 May 2021 00:18:08 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove scratch register from vpmulld

I started our internal testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From gziemski at openjdk.java.net  Wed May 19 16:54:39 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 19 May 2021 16:54:39 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
Message-ID: <9s2SWO6lDaSQEPdXnJPqvyP0kRRoHW62ad3r69oVLV0=.61a9b95c-3605-488e-a685-6b7350d2d134@github.com>

On Wed, 19 May 2021 14:59:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> More than half of the total runtime of the gtests is currently used by just three tests:
>> 
>> - VirtualSpace.os_reserve_space_concurrent_vm
>> - VirtualSpace.os_virtual_space_concurrent_vm
>> - os_linux.reserve_memory_special_concurrent_vm
>> 
>> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
>> 
>> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
>> 
>> ---
>> 
>> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5 threads 3 secs

Had to take look at the `ConcurrentTestRunner` to make sure I understood the parameters:

`ConcurrentTestRunner(TestRunnable* const runnableArg, int nrOfThreadsArg, long testDurationMillisArg)`

Looks good, thank you for fixing it!

-------------

Marked as reviewed by gziemski (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4110

From stuefe at openjdk.java.net  Wed May 19 16:57:44 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 16:57:44 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <9s2SWO6lDaSQEPdXnJPqvyP0kRRoHW62ad3r69oVLV0=.61a9b95c-3605-488e-a685-6b7350d2d134@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
 <9s2SWO6lDaSQEPdXnJPqvyP0kRRoHW62ad3r69oVLV0=.61a9b95c-3605-488e-a685-6b7350d2d134@github.com>
Message-ID: <KY6oIsHnSqomUSVtg4fGM9uOeYuyA_Urpw-qKDb6x70=.7e7ea51d-e10a-4448-93a8-9c2e2c465911@github.com>

On Wed, 19 May 2021 16:52:11 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Had to take look at the `ConcurrentTestRunner` to make sure I understood the parameters:
> 
> `ConcurrentTestRunner(TestRunnable* const runnableArg, int nrOfThreadsArg, long testDurationMillisArg)`
> 
> Looks good, thank you for fixing it!

Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From gziemski at openjdk.java.net  Wed May 19 17:01:45 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 19 May 2021 17:01:45 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
Message-ID: <IWcgCIQB7bgnNQmIzBEU3AtfC4_r8G9KhiJgvxOnkao=.cd8a77ff-57a6-455d-81ed-1518c6c12426@github.com>

On Wed, 19 May 2021 14:59:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> More than half of the total runtime of the gtests is currently used by just three tests:
>> 
>> - VirtualSpace.os_reserve_space_concurrent_vm
>> - VirtualSpace.os_virtual_space_concurrent_vm
>> - os_linux.reserve_memory_special_concurrent_vm
>> 
>> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
>> 
>> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
>> 
>> ---
>> 
>> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5 threads 3 secs

Just one last comment, 3000 ms is 3 seconds, not 5 seconds like you claim, but I'm OK with 3 if that works.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From ayang at openjdk.java.net  Wed May 19 17:05:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 May 2021 17:05:49 GMT
Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste
 since it is never set [v3]
In-Reply-To: <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
References: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
 <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
Message-ID: <KYam5IifLN-j6_-XKjoCBCjIGqVI4jHZAyGvKGV33R8=.555e32ff-ac46-4103-8806-a21fea9be082@github.com>

On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3756

From ayang at openjdk.java.net  Wed May 19 17:05:50 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 May 2021 17:05:50 GMT
Subject: Integrated: 8234532: Remove
 ThreadLocalAllocBuffer::_fast_refill_waste since it is never set
In-Reply-To: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
References: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
Message-ID: <M72WI6jOeqH2yUGrdPeM-wlI9In56bl3a-MW5K8GIZk=.ae40016d-f67c-4b61-9b88-cba21ed77749@github.com>

On Wed, 28 Apr 2021 09:23:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also.

This pull request has now been integrated.

Changeset: 99fcc410
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99fcc410a774e7b830856aa9c8e18e8a3b0567de
Stats:     43 lines in 5 files changed: 0 ins; 36 del; 7 mod

8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set

Reviewed-by: tschatzl, sjohanss, pliden, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3756

From simonis at openjdk.java.net  Wed May 19 17:07:57 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 19 May 2021 17:07:57 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
Message-ID: <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>

On Mon, 17 May 2021 18:27:16 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement the new discard policy: drop the incoming message.
>   
>   This patch also fix a bug. meta messages append to the temp logs instead
>   of directly calling output->write_blocking(). This guranatees logsites are non-blocking.

Hi Xin,

thanks a lot for constantly improving this change. It looks pretty good now. I only have minor comments and some questions. Once these are fixed/answered I'll approve the PR.

Best regards,
Volker

src/hotspot/share/logging/logAsyncWriter.cpp line 64:

> 62:     }
> 63:     // drop the enqueueing message.
> 64:     return;

I don't understand this? If we drop the incoming message `msg`, why do we increment the drop counter for the `LogFileOutput` of the first (i.e. `front()`) enqueued message?
Shouldn't this simply be:

if (_buffer.size() >= _buffer_max_size)  {
  bool p_created;
  uint32_t* counter = _stats.add_if_absent(msg->output(), 0, &p_created);
  *counter = *counter + 1;
  return;

src/hotspot/share/logging/logAsyncWriter.cpp line 125:

> 123: 
> 124: void AsyncLogWriter::perform_IO() {
> 125:   // use kind of copy-and-swap idiom here.

Can you please start new sentences with an uppercase letter.

src/hotspot/share/logging/logAsyncWriter.cpp line 126:

> 124: void AsyncLogWriter::perform_IO() {
> 125:   // use kind of copy-and-swap idiom here.
> 126:   // Empty 'logs' 'swaps' the content with _buffer.

Only quote variables, i.e.: Empty 'logs' swaps the content with '_buffer'.

src/hotspot/share/logging/logAsyncWriter.cpp line 129:

> 127:   // Along with logs destruction, all procceeded messages are deleted.
> 128:   //
> 129:   // the atomic operation 'move' is done in O(1). All I/O jobs are done without lock.

Start with uppercase letter. Replace 'move' by 'pop_all()' because at this point it in?s not obvious that 'pop_all()' eventually calls 'LinkedList::move()'.
What do you mean with "atomic" here? Maybe better remove?

src/hotspot/share/logging/logAsyncWriter.cpp line 175:

> 173:     if (self->_state == ThreadState::Initialized) {
> 174:       Atomic::release_store_fence(&AsyncLogWriter::_instance, self);
> 175:       // all readers of _instance after fence see NULL,

Please start sentences with uppercase letter.

I don't understand this? Wouldn't all readers of '_instance' see 'self' *after* it was stored there with 'Atomic::release_store_fence()`? Or do you wanted to say *before* the fence here?

src/hotspot/share/logging/logAsyncWriter.cpp line 177:

> 175:       // all readers of _instance after fence see NULL,
> 176:       // but we still need to ensure no active reader of any tagset.
> 177:       // After then, we start AsyncLog Thread and it exclusively takes

After **that**...

src/hotspot/share/logging/logAsyncWriter.cpp line 180:

> 178:       // over all logging I/O.
> 179:       for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
> 180:         ts->wait_until_no_readers();

This loop is the only thing I'm not understanding in this whole PR but that doesn't mean it is wrong (it's probably just caused by my limited understanding of UL).
So why do we have to wait here until "there are no more readers" and what does that actually means? Is this necessary to prevent mixing log messages which have been printed before async logging was started?

src/hotspot/share/logging/logAsyncWriter.hpp line 89:

> 87: 
> 88:   LinkedListNode<E>* head() const {
> 89:     return static_cast<const LinkedList<E>* >(this)->head();

Why not simply `return this->_head`?

src/hotspot/share/logging/logAsyncWriter.hpp line 132:

> 130:   // and a variable-length c-string message.
> 131:   // A normal logging  message is smaller than vwrite_buffer_size, which is defined in logtagset.cpp
> 132:   const size_t _buffer_max_size = {AsyncLogBufferSize / (sizeof(AsyncLogMessage) + sizeof(LogDecorations) + vwrite_buffer_size)};

Isn't the `LogDecorations` object part of the `AsyncLogMessage` object? It is stored there as a "value object" not as a reference so its size should already be included in `sizeof(AsyncLogMessage)`.

src/hotspot/share/logging/logConfiguration.cpp line 557:

> 555:   out->print_cr("\nAsynchronous logging(off by default):");
> 556:   out->print_cr(" -Xlog:async");
> 557:   out->print_cr("  All log messages write to an intermediate buffer first and then will be flushed"

All log messages are written to an intermediate buffer first and will then be flushed

src/hotspot/share/logging/logConfiguration.cpp line 606:

> 604:   out->print_cr(" -Xlog:async -Xlog:gc=debug:file=gc.log -Xlog:safepoint=trace");
> 605:   out->print_cr("\t Write logs asynchronously. Enable messages tagged with 'safepoint' up to 'trace' level to stdout ");
> 606:   out->print_cr("\t and messages tagged with 'gc' up to 'trace' level to file 'gc.log'.");

This should read "..up to 'debug' level.."

src/hotspot/share/logging/logDecorations.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2021, Oracle and/or its affiliates. All rights reserved.

No reason to update copyright year if there are no other changes in this file.

src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2021, Oracle and/or its affiliates. All rights reserved.

No reason to update copyright year if there are no other changes in this file.

src/hotspot/share/runtime/thread.hpp line 106:

> 104: //     - WatcherThread
> 105: //     - JfrThreadSampler
> 106: //     - LogAsyncFlusher

I think this should be `AsyncLogWriter`

test/hotspot/gtest/logging/logTestUtils.inline.hpp line 24:

> 22:  */
> 23: 
> 24: #include "jvm.h"

Why do you need this extra include if there are no other changes in this file?

test/hotspot/gtest/logging/test_logDecorations.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2016, 2021, Oracle and/or its affiliates. All rights reserved.

No reason to update copyright year if there are no other changes in this file.

-------------

Changes requested by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From mchung at openjdk.java.net  Wed May 19 17:09:38 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 19 May 2021 17:09:38 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <f2x_xRHhbblGhqxp3I16FrybMdtRQPXDn7PJdaQ-dXk=.c8b80bd2-d2c8-41a0-ae6e-5750b09706da@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
 <cwQrJqXGscoP-cf3HWcWTwW_nGiebz0p_UdgFip7Ed4=.1eb4cad1-7808-46dd-9b2c-96e15b4b35a5@github.com>
 <f2x_xRHhbblGhqxp3I16FrybMdtRQPXDn7PJdaQ-dXk=.c8b80bd2-d2c8-41a0-ae6e-5750b09706da@github.com>
Message-ID: <ZkHL3yAYo4DszraZrLW2JlOeFkwx2KugnxkV6YaH_Ok=.c8d76d48-bf7d-43a6-9224-2fc2561b2599@github.com>

On Wed, 19 May 2021 09:00:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if there needs to be one event per finalized object?

I also concern with the performance overhead of one event per finalized object.

The primary goal of this JFR event is to help identifying the use of finalizers in existing libraries/applications and prepare them to migrate away from using finalization.  As well-known, the finalization mechanism is inherently problematic. 

> Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great.

Therefore, a counter per class would be useful as it identifies the usage of finalizers while providing the number of objects per class pending for finalization (see `ReferenceQueue::enqueue` and `ReferenceQueue::reallyPoll` where it keeps track of the pending for finalization counter).

Another option is to go with a simple approach - just report the aggregated number of `Finalizer` objects per class which still meets the primary goal to identify what existing code uses finalizers and the counter gives the users an additional information how many finalizers are created.

BTW the number of finalizer invocation is not more useful than the number of `Finalizer` instances unless we provide both counters so that the users can determine the number of objects pending for finalization.
 
> Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do.

I agree an event enabled by default is more useful provided that the performance overhead is insignificant.

I was also thinking if this event should be implemented in the VM in order to avoid some performance overhead such as object allocation.  Erin, what is the benefit of implementing in in the VM?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From shade at openjdk.java.net  Wed May 19 17:40:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 19 May 2021 17:40:43 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
Message-ID: <MSGS6uOspz2HgQcP5V10AUCXtdL4FQgshD5tLB7lGng=.b041245a-bf36-4deb-ae3a-68f20496345a@github.com>

On Wed, 19 May 2021 14:59:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> More than half of the total runtime of the gtests is currently used by just three tests:
>> 
>> - VirtualSpace.os_reserve_space_concurrent_vm
>> - VirtualSpace.os_virtual_space_concurrent_vm
>> - os_linux.reserve_memory_special_concurrent_vm
>> 
>> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
>> 
>> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
>> 
>> ---
>> 
>> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5 threads 3 secs

I like it. It seems to reduce "real CPU time" from 10 min to 1.5 min for `CONF=linux-x86_64-server-fastdebug make run-test TEST=jtreg:gtest/LargePageGtests.java`.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4110

From stuefe at openjdk.java.net  Wed May 19 17:55:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 17:55:40 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <IWcgCIQB7bgnNQmIzBEU3AtfC4_r8G9KhiJgvxOnkao=.cd8a77ff-57a6-455d-81ed-1518c6c12426@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
 <IWcgCIQB7bgnNQmIzBEU3AtfC4_r8G9KhiJgvxOnkao=.cd8a77ff-57a6-455d-81ed-1518c6c12426@github.com>
Message-ID: <kpoRw8ns_Aq3YGzULfD6pmvOSGpqu4J7XJuwxA1S8Kg=.200aefe8-675b-407b-b052-50a7a3f5ca3a@github.com>

On Wed, 19 May 2021 16:58:38 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Just one last comment, 3000 ms is 3 seconds, not 5 seconds like you claim, but I'm OK with 3 if that works.

Yes, I downgraded it first to 5secs, then to 3secs after talking to stefank. Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From stuefe at openjdk.java.net  Wed May 19 17:55:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 17:55:40 GMT
Subject: RFR: JDK-8267371: Concurrent gtests take too long [v2]
In-Reply-To: <MSGS6uOspz2HgQcP5V10AUCXtdL4FQgshD5tLB7lGng=.b041245a-bf36-4deb-ae3a-68f20496345a@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
 <qdlhAwnrF_8WlcCgZhnsDIvSfxKY5fZR5rypkjuoDxU=.f817e7cc-a345-4a4d-8785-b2c5335e2f42@github.com>
 <MSGS6uOspz2HgQcP5V10AUCXtdL4FQgshD5tLB7lGng=.b041245a-bf36-4deb-ae3a-68f20496345a@github.com>
Message-ID: <s4UO0v6DYtp88igSWo-UxU7BI9QMbuqeAuv1_moYps8=.2ebe7135-ccf9-4ba1-8701-34b4cf84d9c4@github.com>

On Wed, 19 May 2021 17:37:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I like it. It seems to reduce "real CPU time" from 10 min to 1.5 min for `CONF=linux-x86_64-server-fastdebug make run-test TEST=jtreg:gtest/LargePageGtests.java`.

Great, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From stuefe at openjdk.java.net  Wed May 19 17:58:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 19 May 2021 17:58:48 GMT
Subject: Integrated: JDK-8267371: Concurrent gtests take too long
In-Reply-To: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
References: <DZRzwsEZ1g8p3g7hcLWG_6kT1Dy9FvWbmIqNTuI2c7s=.7bee3f43-f5b7-426f-83ae-e1d6413370ef@github.com>
Message-ID: <KJwKGLBD953psQiOMe56vzN2rX-uHlMsz05HTglO96c=.fa238415-9475-47a5-846f-441a563aa6d5@github.com>

On Wed, 19 May 2021 08:30:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> More than half of the total runtime of the gtests is currently used by just three tests:
> 
> - VirtualSpace.os_reserve_space_concurrent_vm
> - VirtualSpace.os_virtual_space_concurrent_vm
> - os_linux.reserve_memory_special_concurrent_vm
> 
> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
> 
> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
> 
> ---
> 
> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.

This pull request has now been integrated.

Changeset: 9820f3d4
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9820f3d480aa2e6813596710348b2057a8c2a572
Stats:     7 lines in 2 files changed: 2 ins; 0 del; 5 mod

8267371: Concurrent gtests take too long

Reviewed-by: shade, gziemski

-------------

PR: https://git.openjdk.java.net/jdk/pull/4110

From egahlin at openjdk.java.net  Wed May 19 17:59:40 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 May 2021 17:59:40 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
Message-ID: <4_QSMcxN46M-A1ZxjNPkHECuutCfsQMpZ3MiCca6JtA=.64fdccff-f40b-40c6-af5a-65cc5fc8883e@github.com>

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

> I was also thinking if this event should be implemented in the VM in order to avoid some performance overhead such as object allocation. Erik, what is the benefit of implementing in in the VM?

No startup cost, no allocation and there are callbacks when a class gets unloaded, so it's probably easier to clear any table where the statistics is held.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From xliu at openjdk.java.net  Wed May 19 18:08:51 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 19 May 2021 18:08:51 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
Message-ID: <7WA_YIFz-JUVhJIUYWJtOVSrkDigY7LcASxoWDAcrXs=.4b6eaf0f-229a-40cd-b1df-3a4755619176@github.com>

On Wed, 19 May 2021 16:54:48 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement the new discard policy: drop the incoming message.
>>   
>>   This patch also fix a bug. meta messages append to the temp logs instead
>>   of directly calling output->write_blocking(). This guranatees logsites are non-blocking.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 180:
> 
>> 178:       // over all logging I/O.
>> 179:       for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
>> 180:         ts->wait_until_no_readers();
> 
> This loop is the only thing I'm not understanding in this whole PR but that doesn't mean it is wrong (it's probably just caused by my limited understanding of UL).
> So why do we have to wait here until "there are no more readers" and what does that actually means? Is this necessary to prevent mixing log messages which have been printed before async logging was started?

I would like to consolidate "exclusively". Once async logging takes over, we guarantee that no synchronous logsite is writing files in concurrency.  If we guarantee that, we can avoid FileLocker() because only AsyncLog Thread writes files. 

Fence isn't enough here. fence can only guarantee that logsites 'after' the fence use async logging.  It's possible that there are on-going synchronous logging. 

This is a RCU trick of Unified logging.  RCU is kind of synchronization biased to multiple readers. `LogOutputList::Iterator` actually embeds an atomic counter.
ts->wait_until_no_readers() waits until all readers finish. It means that all synchronous write have done. 

here is how synchronous log writes. Iterator increases to zero when the loop is done. 
 

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);
  }
}```

> src/hotspot/share/logging/logAsyncWriter.hpp line 132:
> 
>> 130:   // and a variable-length c-string message.
>> 131:   // A normal logging  message is smaller than vwrite_buffer_size, which is defined in logtagset.cpp
>> 132:   const size_t _buffer_max_size = {AsyncLogBufferSize / (sizeof(AsyncLogMessage) + sizeof(LogDecorations) + vwrite_buffer_size)};
> 
> Isn't the `LogDecorations` object part of the `AsyncLogMessage` object? It is stored there as a "value object" not as a reference so its size should already be included in `sizeof(AsyncLogMessage)`.

yes, I changed logDecoration from pointer to value. I will update the comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <fiq_yIbqC9QRDEcRvYChJl6aWrZvnOxZM4uuDdwYDek=.bbe622b3-b90a-4441-bb0c-ead59bca50d2@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <hfPqSTPSSpxjLndppmuJovqQVW7q2UXmBhzI8sIGDJg=.bdef2a7d-72bd-49ac-b7f6-9ca56ce3cd1e@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From xliu at openjdk.java.net  Wed May 19 18:21:55 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 19 May 2021 18:21:55 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
Message-ID: <HbAzueLDgde7XL5whcTcRuQqYikwqacRIbvgMwgtVSw=.23778fd7-d1d3-4461-a5d5-189e22b2a0c6@github.com>

On Thu, 13 May 2021 06:34:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 106:
> 
>> 104: 
>> 105:   log_info(logging)("The maximum entries of AsyncLogBuffer: " SIZE_FORMAT ", estimated memory use: " SIZE_FORMAT " bytes",
>> 106:                     _buffer_max_size, AsyncLogBufferSize);
> 
> nit: how about "Asynchronous logging enabled. Buffer size: xxx entries"?

I change the logic a little bit. 
at this point we can't say "Asynchronous logging enabled", we need to make sure:
1. asynclog Thread is ready.
2. _instance is non-null.
3. all active readers(synchronous logsites) are completed. 

I emit a sentence later. 
[0.036s][27407][debug][logging,thread   ] AsyncLogging starts working.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Wed May 19 18:26:00 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 19 May 2021 18:26:00 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
Message-ID: <qk_DAI9f-nmSMHOiSiZCso7s_-8jFUdCywKriEIO6SA=.a3cb89e1-acaa-4b6b-9e08-69a5a57c36a3@github.com>

On Wed, 19 May 2021 12:16:27 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement the new discard policy: drop the incoming message.
>>   
>>   This patch also fix a bug. meta messages append to the temp logs instead
>>   of directly calling output->write_blocking(). This guranatees logsites are non-blocking.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 64:
> 
>> 62:     }
>> 63:     // drop the enqueueing message.
>> 64:     return;
> 
> I don't understand this? If we drop the incoming message `msg`, why do we increment the drop counter for the `LogFileOutput` of the first (i.e. `front()`) enqueued message?
> Shouldn't this simply be:
> 
> if (_buffer.size() >= _buffer_max_size)  {
>   bool p_created;
>   uint32_t* counter = _stats.add_if_absent(msg->output(), 0, &p_created);
>   *counter = *counter + 1;
>   return;

you are right. I will change this. 
in previous implementation, I pop_front() and enqueue msg. 
I didn't clean up everything.

> src/hotspot/share/logging/logAsyncWriter.cpp line 125:
> 
>> 123: 
>> 124: void AsyncLogWriter::perform_IO() {
>> 125:   // use kind of copy-and-swap idiom here.
> 
> Can you please start new sentences with an uppercase letter.

Okay.

> src/hotspot/share/logging/logConfiguration.cpp line 606:
> 
>> 604:   out->print_cr(" -Xlog:async -Xlog:gc=debug:file=gc.log -Xlog:safepoint=trace");
>> 605:   out->print_cr("\t Write logs asynchronously. Enable messages tagged with 'safepoint' up to 'trace' level to stdout ");
>> 606:   out->print_cr("\t and messages tagged with 'gc' up to 'trace' level to file 'gc.log'.");
> 
> This should read "..up to 'debug' level.."

yes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
Message-ID: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>

On Wed, 19 May 2021 18:26:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mchung at openjdk.java.net  Wed May 19 18:43:40 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 19 May 2021 18:43:40 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <4_QSMcxN46M-A1ZxjNPkHECuutCfsQMpZ3MiCca6JtA=.64fdccff-f40b-40c6-af5a-65cc5fc8883e@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
 <Xz5jsO9mXHSfVpXxVsCT8oHsVUIi_9_jMTaxlyXMJsk=.716ebc58-a691-4228-9ed1-b502cdc74ff5@github.com>
 <4_QSMcxN46M-A1ZxjNPkHECuutCfsQMpZ3MiCca6JtA=.64fdccff-f40b-40c6-af5a-65cc5fc8883e@github.com>
Message-ID: <ZJcfbETyuWKczYAFO27mvHw1pVUbYwq17Sn6dyiNJ6o=.c644ff3d-559d-415d-b161-949b2c9b8695@github.com>

On Wed, 19 May 2021 17:57:11 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > I was also thinking if this event should be implemented in the VM in order to avoid some performance overhead such as object allocation. Erik, what is the benefit of implementing in in the VM?
> 
> No startup cost, no allocation and there are callbacks when a class gets unloaded, so it's probably easier to clear any table where the statistics is held.

Thanks for the confirmation.   This is performance sensitive area and so it's worth considering doing it in the VM.  In either case, performance measurement of the overhead will tell.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101

From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
Message-ID: <P1n8uhHy1IqLsvr2AH5wQb1wuBkGPofCg2TFvelA4sQ=.1cbb03a5-084d-4548-be7c-fa66b9968f87@github.com>

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From psandoz at openjdk.java.net  Wed May 19 19:26:44 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 19 May 2021 19:26:44 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v9]
In-Reply-To: <IZCPfVXiQLsnfq98MOqZ9pOJH0SzvXb_dwZ_RZAZQgc=.40effb0c-fc0b-4ba5-8c91-a32b02447cb8@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <IZCPfVXiQLsnfq98MOqZ9pOJH0SzvXb_dwZ_RZAZQgc=.40effb0c-fc0b-4ba5-8c91-a32b02447cb8@github.com>
Message-ID: <lLhZZU3iGwWI-F4-OoLPSa--n_Av_mlNbdeoWvZLuUk=.e16be7b8-12df-41e4-9302-4b03a9eb5d50@github.com>

On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix 32-bit build

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 723:

> 721: #end[BITWISE]
> 722: #if[FP]
> 723:                 case VECTOR_OP_OR: return (v0, v1) ->

`VECTOR_OP_OR` looks incorrect, since `VectorOperators.OR` is not applicable to FP types.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From coleenp at openjdk.java.net  Wed May 19 20:08:13 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 19 May 2021 20:08:13 GMT
Subject: RFR: 8267396: Avoid recording "pc" in unhandled oops detector for
 better performance
In-Reply-To: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>
References: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>
Message-ID: <7aewsZmPLRCXa2d9d0XOVtoktOErbJehbx0s7D7yWE4=.e2bcb1f8-15e8-40e0-ac23-e505522b8d47@github.com>

On Wed, 19 May 2021 12:32:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the rationale in the bug.
> 
> Additional testing:
>  - [x] Known slow test with `-XX:+CheckUnhandledOops`
>  - [x] tier1 with `-XX:+CheckUnhandledOops`

This is fine.  I don't remember why I thought the pc was helpful when I added it. Thanks.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4114

From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <faOe6m8bn6J0ZmXT2mXeQnXapiwOqEixCz4qYhAXRSk=.ec7435aa-b851-4be2-88d2-f122f3fea099@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From manc at openjdk.java.net  Wed May 19 21:05:32 2021
From: manc at openjdk.java.net (Man Cao)
Date: Wed, 19 May 2021 21:05:32 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <yweU_Pz80C6uPpCHS0-ZIWpXf_Mzz1TfxfrXZ4Hk8BE=.b90398e7-8bc0-41a1-8c02-d3dc21850511@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Re Robbin's comment:

Yes, if the G1 epoch sync protocol uses async handshake, it should either not to issue too many handshakes that are left unexecuted, or drain all pending handshakes at a safepoint. Currently the implementation does not do that so it could cause leaks.

G1AsyncEpochHandshakeClosure is indeed a no-op, and the protocol only needs the fence. It actually only needs the target thread to execute `G1EpochUpdater::update_epoch_self()` at some point, which contains a StoreStore fence and is sufficient for creating release-acquire edges. I'll try this arm-the-poll-only approach.

What do you think about this change though? It is still a reasonable refactoring that enables more use cases of async handshakes (although not necessarily for G1 epoch sync protocol), right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From manc at openjdk.java.net  Wed May 19 21:35:28 2021
From: manc at openjdk.java.net (Man Cao)
Date: Wed, 19 May 2021 21:35:28 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <wk-QtIr3J0eKusnWzzwbtHOyxuJsoDkSMDgynDQPdlI=.cf74fcc9-af82-4010-ac6d-c6c361bc4ee1@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Re David's comment:

> Though if there is a self-only async op in the queue ahead of that, then you won't be able to proceed anyway.

I don't quite understand this part. After this change, in `HandshakeState::try_process()`, the do...while loop calls `HandshakeState::pop()` inside, which will skip those self-only async ops, right?  Then it can still process those non-self executable async ops.

> Not really getting this part. Why do you want to skip blocked threads?
> ...
> if a thread is blocked then it is handshake-safe and so the handshake should be fast.
> Or are you concerned that your handshake won't be able to proceed
> because of what else may be in a target thread's op queue, and you want
> to skip that target in that case?

Perhaps "skipping" is a bad choice of word. In the latest implementation for epoch sync protocol, the requesting thread still issues the async handshake to blocked threads. The requesting thread then checks whether the target thread is blocked, if so, it updates the target thread's epoch counter on behalf of the target thread, then the epoch sync is done for this target thread. This is the same as the way that  `Handshake::execute()` executes a synchronous handshake op on behalf of a blocked target thread. If the target thread is not blocked, the requesting thread can only wait, and possibly time out and give up.

Currently just running `Handshake::execute()` for a target thread could run into a safepoint, and it does not support timeout or giving up. These behaviors do not work for G1's refinement. This is the reason I'm using enqueue-only async submission, and also need a way to check for threads that are blocked, in order to quickly finish the epoch sync with blocked threads.

With the arm-the-poll-only approach Robbin suggested, I think it still needs a way to check for blocked threads, and update the blocked thread's epoch counter on behalf of the blocked thread. I could do that in the change for JDK-8236485, or split it up in another RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From sviswanathan at openjdk.java.net  Wed May 19 21:55:07 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 21:55:07 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v10]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <hSyfR7iJdH7Y0sdNSFsFozlKLn42MGMMZRKotae06PE=.f64be6e3-314b-4dbd-8431-9a03b7f9c573@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Implement Vladimir Ivanov and Paul Sandoz review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/f7e39913..0b4a1c9c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=08-09

  Stats: 45 lines in 1 file changed: 0 ins; 45 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>

On Wed, 19 May 2021 19:31:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From sviswanathan at openjdk.java.net  Wed May 19 21:58:37 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 21:58:37 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
 <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
Message-ID: <DWhDCjFYPge3kXS6riDpjpagECzoSq_FyurX73UTQ50=.769a9970-28d3-4263-969e-e3c4749b5b8d@github.com>

On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge master
>>  - remove whitespace
>>  - Merge master
>>  - Small fix
>>  - cleanup
>>  - x86 short vector math optimization for Vector API
>
> Tier 1 to 3 tests pass for the default set of build profiles.

Thanks a lot for the review @PaulSandoz @iwanowww @erikj79.
Paul and Vladimir, I have implemented your review comments. Please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From psandoz at openjdk.java.net  Wed May 19 22:05:59 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 19 May 2021 22:05:59 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
 <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
Message-ID: <ByDQehaptU8bBPXiviiDlJi9PLZbKElxbrhplKzkmd0=.36e41a51-3265-4c5d-b047-3bd037be55c8@github.com>

On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge master
>>  - remove whitespace
>>  - Merge master
>>  - Small fix
>>  - cleanup
>>  - x86 short vector math optimization for Vector API
>
> Tier 1 to 3 tests pass for the default set of build profiles.

> Thanks a lot for the review @PaulSandoz @iwanowww @erikj79.
> Paul and Vladimir, I have implemented your review comments. Please take a look.

`case VECTOR_OP_OR` is still present.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
Message-ID: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From sviswanathan at openjdk.java.net  Wed May 19 22:16:18 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 22:16:18 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v11]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <eSY8J2s2SSOXn9oCEcwrvTk9HaCtue-sNSCB_JWLymY=.4bf047c3-82dc-4b35-a248-fe259167c217@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Commit missing changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/0b4a1c9c..1b0367ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=09-10

  Stats: 55 lines in 16 files changed: 2 ins; 42 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Wed May 19 22:16:19 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 22:16:19 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <ByDQehaptU8bBPXiviiDlJi9PLZbKElxbrhplKzkmd0=.36e41a51-3265-4c5d-b047-3bd037be55c8@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>
 <tGiBVAHq3R_ylcQYN5iAOl7MAQLl6gxPsdb32E9c7m8=.2710d8b3-5fbe-4fa2-b181-1a299ddd2dd7@github.com>
 <ByDQehaptU8bBPXiviiDlJi9PLZbKElxbrhplKzkmd0=.36e41a51-3265-4c5d-b047-3bd037be55c8@github.com>
Message-ID: <5ncMaHLhmfOv3FBOrYSkKmzVXHwQqFks-RPcjuC02Mo=.31de0845-e60a-413a-8984-0ce6e4eac2ed@github.com>

On Wed, 19 May 2021 22:02:14 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Tier 1 to 3 tests pass for the default set of build profiles.
>
>> Thanks a lot for the review @PaulSandoz @iwanowww @erikj79.
>> Paul and Vladimir, I have implemented your review comments. Please take a look.
> 
> `case VECTOR_OP_OR` is still present.

@PaulSandoz Thanks for pointing that out. I had missed git add for some of the files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3638

From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From psandoz at openjdk.java.net  Wed May 19 22:29:32 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 19 May 2021 22:29:32 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v11]
In-Reply-To: <eSY8J2s2SSOXn9oCEcwrvTk9HaCtue-sNSCB_JWLymY=.4bf047c3-82dc-4b35-a248-fe259167c217@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
 <eSY8J2s2SSOXn9oCEcwrvTk9HaCtue-sNSCB_JWLymY=.4bf047c3-82dc-4b35-a248-fe259167c217@github.com>
Message-ID: <Ck3sswwPB6Ha-ovrAWBd9us2pnfUUaoX8eDKJzTSNxA=.fcd6d51f-df0e-4c94-bef5-50c159c57fae@github.com>

On Wed, 19 May 2021 22:16:18 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
>> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
>> 
>> The following changes are made:
>>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>>    Changes are made to build system to support dependency tracking for assembly files with includes.
>>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
>> 
>> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
>> 
>> Looking forward to your review and feedback.
>> 
>> Performance:
>> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
>> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
>> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
>> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
>> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
>> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
>> Double128Vector.COS 49.94 245.89 ops/ms 4.92
>> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
>> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
>> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
>> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
>> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
>> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
>> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
>> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
>> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
>> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
>> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
>> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
>> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
>> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
>> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
>> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
>> Double256Vector.COS 58.26 389.77 ops/ms 6.69
>> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
>> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
>> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
>> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
>> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
>> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
>> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
>> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
>> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
>> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
>> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
>> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
>> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
>> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
>> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
>> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
>> Double512Vector.COS 59.88 837.04 ops/ms 13.98
>> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
>> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
>> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
>> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
>> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
>> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
>> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
>> Double512Vector.POW 37.42 384.13 ops/ms 10.26
>> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
>> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
>> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
>> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
>> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
>> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
>> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
>> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
>> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
>> Double64Vector.COS 23.42 152.01 ops/ms 6.49
>> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
>> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
>> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
>> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
>> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
>> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
>> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
>> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
>> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
>> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
>> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
>> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
>> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
>> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
>> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
>> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
>> Float128Vector.COS 42.82 803.02 ops/ms 18.75
>> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
>> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
>> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
>> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
>> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
>> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
>> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
>> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
>> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
>> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
>> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
>> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
>> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
>> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
>> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
>> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
>> Float256Vector.COS 43.75 926.69 ops/ms 21.18
>> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
>> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
>> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
>> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
>> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
>> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
>> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
>> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
>> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
>> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
>> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
>> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
>> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
>> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
>> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
>> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
>> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
>> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
>> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
>> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
>> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
>> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
>> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
>> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
>> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
>> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
>> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
>> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
>> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
>> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
>> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
>> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
>> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
>> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
>> Float64Vector.COS 44.28 394.33 ops/ms 8.91
>> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
>> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
>> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
>> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
>> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
>> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
>> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
>> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
>> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
>> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
>> Float64Vector.TANH 47.65 214.04 ops/ms 4.49
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Commit missing changes

> @PaulSandoz Thanks for pointing that out. I had missed git add for some of the files.

Java changes look good.

Please don't integrate when checks pass. I need to work through some JEP details first before we can integrate relevant PRs.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Wed May 19 22:52:09 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 22:52:09 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v12]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <rYaiWvCCg_qEusRpLqt7Gd2s7pjWbUYSG0j_7PJWBwc=.28ec43b3-cee3-4627-87df-472b94e03bcb@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge master
 - Commit missing changes
 - Implement Vladimir Ivanov and Paul Sandoz review comments
 - fix 32-bit build
 - Add comments explaining naming convention
 - jcheck fixes
 - Print intrinsic fix
 - Implement review comments
 - Add missing Lib.gmk
 - Merge master
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/b961f253...7b959b67

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=11
  Stats: 416021 lines in 119 files changed: 415854 ins; 124 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Wed May 19 23:01:09 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 19 May 2021 23:01:09 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v13]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <L93XDKDWirOdL9ar09EQVEglZi2pSYVqZLsYL2k_Ib8=.f8c8a1d8-c979-4d56-a1f0-106d2886e8e7@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  correct ppc.ad

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/7b959b67..4d59af0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=11-12

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From kvn at openjdk.java.net  Wed May 19 23:47:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 19 May 2021 23:47:45 GMT
Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v11]
In-Reply-To: <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
 <0mKzVE9RTWU0ZxjILDLkFx6EW-skdsp3lshNPbucuik=.4e19c3b0-7a3a-47f0-a008-21d999f24c15@github.com>
Message-ID: <f6zVb6Ldfh19jAvwkGOOx6ryRn5FLTfSaPf3Nl6fNNA=.893221e6-0c81-4945-9e66-b794b49e5819@github.com>

On Tue, 18 May 2021 00:18:08 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
>> 
>> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
>> 
>> For this benchmark,  the optimization shows ~5x improvement.
>> 
>> Base:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
>> 
>> 
>> With patch:
>> Benchmark (count) Mode Cnt Score Error Units
>> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
>> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
>> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
>> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
>> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
>> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
>> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove scratch register from vpmulld

tier1-3 testing is clean. It ran compiler/intrinsics/zip/TestAdler32.java test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From github.com+58006833+xbzhang99 at openjdk.java.net  Wed May 19 23:47:49 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Wed, 19 May 2021 23:47:49 GMT
Subject: Integrated: 8266332: Adler32 intrinsic for x86 64-bit platforms
In-Reply-To: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
References: <mcsH80b60W4-Vxd1EhNwF_PRnQyYVlzG0ENlMcxsbcE=.24e5139b-8ebb-4977-bb0c-ac55d641b081@github.com>
Message-ID: <HSYNVNQfQR_KcLXsUPKjgsxDdOEirj1VwoWplLK1p6o=.f1d52b48-0e0e-4ce4-804f-7225e6d1bbdf@github.com>

On Thu, 29 Apr 2021 23:47:17 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions.
> 
> The benchmark test/micro/org/openjdk/bench/java/util/TestAdler32.java is contributed by Pengfei Li (pli, Pengfei.Li at arm.com).
> 
> For this benchmark,  the optimization shows ~5x improvement.
> 
> Base:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op
> 
> 
> With patch:
> Benchmark (count) Mode Cnt Score Error Units
> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op
> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op
> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op
> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op
> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op
> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op
> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op

This pull request has now been integrated.

Changeset: 8e3549fc
Author:    Xubo Zhang <xubo.zhang at intel.com>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e3549fc736539a45534dfe2b417170b5c991c7d
Stats:     399 lines in 13 files changed: 393 ins; 5 del; 1 mod

8266332: Adler32 intrinsic for x86 64-bit platforms

Co-authored-by: Xubo Zhang <xubo.zhang at intel.com>
Co-authored-by: Greg B Tucker <greg.b.tucker at intel.com>
Co-authored-by: Pengfei Li <pli at openjdk.org>
Reviewed-by: sviswanathan, jbhateja, kvn, neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/3806

From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
Message-ID: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>

On Wed, 19 May 2021 23:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
Message-ID: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From david.holmes at oracle.com  Thu May 20 02:47:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 May 2021 12:47:57 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <wk-QtIr3J0eKusnWzzwbtHOyxuJsoDkSMDgynDQPdlI=.cf74fcc9-af82-4010-ac6d-c6c361bc4ee1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
 <wk-QtIr3J0eKusnWzzwbtHOyxuJsoDkSMDgynDQPdlI=.cf74fcc9-af82-4010-ac6d-c6c361bc4ee1@github.com>
Message-ID: <db6ebd97-1b76-5c7b-45bc-6455ab4f5753@oracle.com>

On 20/05/2021 7:35 am, Man Cao wrote:
> On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:
> 
>>> Hi all,
>>>
>>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>>>
>>> -Man
>>
>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Added missing deallocation and renamed "remote" to "non-self".
> 
> Re David's comment:
> 
>> Though if there is a self-only async op in the queue ahead of that, then you won't be able to proceed anyway.
> 
> I don't quite understand this part. After this change, in `HandshakeState::try_process()`, the do...while loop calls `HandshakeState::pop()` inside, which will skip those self-only async ops, right?  Then it can still process those non-self executable async ops.

I thought we had to preserve the order of handshake operations? (In the 
same way the safepoint operations were previously well ordered.) If that 
is not the case ... there might be some subtle interactions there that 
might lead to very hard to diagnose bugs.

>> Not really getting this part. Why do you want to skip blocked threads?
>> ...
>> if a thread is blocked then it is handshake-safe and so the handshake should be fast.
>> Or are you concerned that your handshake won't be able to proceed
>> because of what else may be in a target thread's op queue, and you want
>> to skip that target in that case?
> 
> Perhaps "skipping" is a bad choice of word. In the latest implementation for epoch sync protocol, the requesting thread still issues the async handshake to blocked threads. The requesting thread then checks whether the target thread is blocked, if so, it updates the target thread's epoch counter on behalf of the target thread, then the epoch sync is done for this target thread. This is the same as the way that  `Handshake::execute()` executes a synchronous handshake op on behalf of a blocked target thread. If the target thread is not blocked, the requesting thread can only wait, and possibly time out and give up.

As I don't know anything about the epoch sync protocol I don't really 
understand the requirements here. If you are prepared to have some 
threads defer execution of the async handshake indefinitely (because 
they aren't blocked) then why do you need to ensure you update the 
counter for other threads, rather than have them do it themselves when 
they are able to execute the async handshake op?

> Currently just running `Handshake::execute()` for a target thread could run into a safepoint, and it does not support timeout or giving up. These behaviors do not work for G1's refinement. This is the reason I'm using enqueue-only async submission, and also need a way to check for threads that are blocked, in order to quickly finish the epoch sync with blocked threads.

I get the need for async submission. I don't get why you need to do 
something for the blocked threads rather than them doing it themselves 
later when they unblock. Though that is a distinct issue from whether 
the mechanism should exist.

Cheers,
David
-----

> With the arm-the-poll-only approach Robbin suggested, I think it still needs a way to check for blocked threads, and update the blocked thread's epoch counter on behalf of the blocked thread. I could do that in the change for JDK-8236485, or split it up in another RFE.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From dholmes at openjdk.java.net  Thu May 20 02:59:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 20 May 2021 02:59:28 GMT
Subject: RFR: 8267396: Avoid recording "pc" in unhandled oops detector for
 better performance
In-Reply-To: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>
References: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>
Message-ID: <tZhE_IiP4Bx5oY9K7aBe5PYoFX738RzX6JilnH9o0co=.fe96f9ba-8f72-4666-a8ae-16ac45432475@github.com>

On Wed, 19 May 2021 12:32:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the rationale in the bug.
> 
> Additional testing:
>  - [x] Known slow test with `-XX:+CheckUnhandledOops`
>  - [x] tier1 with `-XX:+CheckUnhandledOops`

LGTM2 :)

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4114

From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>

On Thu, 20 May 2021 04:05:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From manc at openjdk.java.net  Thu May 20 05:44:44 2021
From: manc at openjdk.java.net (Man Cao)
Date: Thu, 20 May 2021 05:44:44 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <db6ebd97-1b76-5c7b-45bc-6455ab4f5753@oracle.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <db6ebd97-1b76-5c7b-45bc-6455ab4f5753@oracle.com>
Message-ID: <LMPGCuFyK1nKNFZoRmlUEhZu6AFcqTP0UFOKcNewosg=.3173507f-92a7-4cbe-9720-4930a18d987f@github.com>

On Thu, 20 May 2021 02:50:07 GMT, David Holmes <david.holmes at oracle.com> wrote:

> I thought we had to preserve the order of handshake operations? (In the
> same way the safepoint operations were previously well ordered.) If that
> is not the case ... there might be some subtle interactions there that
> might lead to very hard to diagnose bugs.

I'm not sure about this. Currently without this change, if there are both async self-executed ops and synchronous non-self executable ops on the queue, it would not preserve the execution order.
I think non-self executable ops and self-executed ops shouldn't depend on each other. It would be a misuse of handshakes if that happens.

> As I don't know anything about the epoch sync protocol I don't really
> understand the requirements here. If you are prepared to have some
> threads defer execution of the async handshake indefinitely (because
> they aren't blocked) then why do you need to ensure you update the
> counter for other threads, rather than have them do it themselves when
> they are able to execute the async handshake op?

The epoch sync protocol only needs the target thread to execute a memory fence, or become blocked. The purpose is to flush out all potential stores to Java heap, or establish a release-acquire edge from the target thread to requesting thread. It is essentially an asymmetric Dekker synchronization (see [this article](https://blogs.oracle.com/dave/qpi-quiescence)). The role of handshake is like a "membarrier" Linux syscall on the target thread. This is why the actual handshake op is a no-op, and the arm-the-poll-only approach as Robbin suggested is superior.

For this question, it is because:
- We want to minimize the number of deferred ops, because deferring means more work during the later GC pause. In fact, with a timeout of 2-3 milliseconds, it is extremely rare to have deferred ops already.
- A blocked thread may not come back to in_Java for a long time, so it will not execute any self-executed async op. If we don't handle them, most ops will become deferred if there's a blocked thread. In a realistic large server, it is common to have hundreds or thousands of Java threads, and a large portion of them are blocked on Object.wait() and rarely become running.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From david.holmes at oracle.com  Thu May 20 06:49:50 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 May 2021 16:49:50 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <LMPGCuFyK1nKNFZoRmlUEhZu6AFcqTP0UFOKcNewosg=.3173507f-92a7-4cbe-9720-4930a18d987f@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <db6ebd97-1b76-5c7b-45bc-6455ab4f5753@oracle.com>
 <LMPGCuFyK1nKNFZoRmlUEhZu6AFcqTP0UFOKcNewosg=.3173507f-92a7-4cbe-9720-4930a18d987f@github.com>
Message-ID: <bfdb0469-347e-56a1-84d1-7523832e5513@oracle.com>

On 20/05/2021 3:44 pm, Man Cao wrote:
> On Thu, 20 May 2021 02:50:07 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> I thought we had to preserve the order of handshake operations? (In the
>> same way the safepoint operations were previously well ordered.) If that
>> is not the case ... there might be some subtle interactions there that
>> might lead to very hard to diagnose bugs.
> 
> I'm not sure about this. Currently without this change, if there are both async self-executed ops and synchronous non-self executable ops on the queue, it would not preserve the execution order.
> I think non-self executable ops and self-executed ops shouldn't depend on each other. It would be a misuse of handshakes if that happens.

Hmmm. I had a mental model where order of ops was preserved. Introducing 
non-determinism in the order in which ops are executed seems potentially 
fragile - and a new mode of operation compared to safepoint VM 
operations. That said, taking suspension as an an example, if the target 
thread is off in native when suspended, and so could not process the 
async handshake op for suspension yet, then we would still want a 
synchronous handshake op to dump its stack to work.

But I'm not at all convinced that there may not be any ordering 
dependencies ever. Maybe it is a misuse, but how hard will be it be to 
spot this misuse, or debug it ? (rhetorical question)

>> As I don't know anything about the epoch sync protocol I don't really
>> understand the requirements here. If you are prepared to have some
>> threads defer execution of the async handshake indefinitely (because
>> they aren't blocked) then why do you need to ensure you update the
>> counter for other threads, rather than have them do it themselves when
>> they are able to execute the async handshake op?
> 
> The epoch sync protocol only needs the target thread to execute a memory fence, or become blocked. The purpose is to flush out all potential stores to Java heap, or establish a release-acquire edge from the target thread to requesting thread. It is essentially an asymmetric Dekker synchronization (see [this article](https://blogs.oracle.com/dave/qpi-quiescence)). The role of handshake is like a "membarrier" Linux syscall on the target thread. This is why the actual handshake op is a no-op, and the arm-the-poll-only approach as Robbin suggested is superior.
> 
> For this question, it is because:
> - We want to minimize the number of deferred ops, because deferring means more work during the later GC pause. In fact, with a timeout of 2-3 milliseconds, it is extremely rare to have deferred ops already.

If the deferred op is a no-op then I'm not sure how this creates work 
for a later GC pause. Assume all the Java threads are executing in 
native and stay there for a long time - why should that impact the GC's 
work?

> - A blocked thread may not come back to in_Java for a long time, so it will not execute any self-executed async op. If we don't handle them, most ops will become deferred if there's a blocked thread. In a realistic large server, it is common to have hundreds or thousands of Java threads, and a large portion of them are blocked on Object.wait() and rarely become running.

So taking an extreme example, if a thread is blocked for a few minutes 
(or equivalently, but less likely, is in native) then you are concerned 
that many of these epoch-sync async ops will accumulate, and that could 
cause memory pressure and slowdown the thread's return to Java. I can 
see that is a concern. But the first thought I had in relation to this 
problem was that perhaps we need to introduce the notion of coalescable 
operations: if all epoch-sync operations are equivalent then you only 
need at most one to get enqueued. Of course then we have to scan the 
queue for an existing occurrence. But that seems more general a solution 
to unbounded deferred operations than introducing a way to "skip" 
blocked threads.

I think it is important to flesh out the requirements here to ensure 
we're making strategic design decisions about the overall architecture 
of the handshake mechanism, rather than just trying to tweak the 
mechanism to support a specific use case. So sorry for the delay this 
adds, but I think the discussions are important.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
Message-ID: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>

On Thu, 20 May 2021 04:22:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From manc at openjdk.java.net  Thu May 20 07:33:30 2021
From: manc at openjdk.java.net (Man Cao)
Date: Thu, 20 May 2021 07:33:30 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <SAttDGHN5cKh4gXqNuNCRbx6y8QvOo7J8QLavc_AbsA=.4168e46b-5875-4f93-aa82-15fb6aeec9c3@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Thanks again. Yes, the discussion here is really helpful.

> But I'm not at all convinced that there may not be any ordering
> dependencies ever. Maybe it is a misuse, but how hard will be it be to
> spot this misuse, or debug it ? (rhetorical question)

Do we agree that for this change we don't need to preserve the order yet? Preserving the order probably needs a separate RFE and more discussion. It should be considered again if there are more async non-self executable ops in the future.

> If the deferred op is a no-op then I'm not sure how this creates work
> for a later GC pause. Assume all the Java threads are executing in
> native and stay there for a long time - why should that impact the GC's
> work?

The actual work is to refine the dirty card. There are 3 major steps to refine a dirty card with G1 epoch sync:
1. Clean the card
2. Do the epoch sync protocol with all Java threads
3. If the epoch sync is successful, refine the cleaned card. If unsuccessful, defer the card to be checked and refined later, or to be processed in the next incremental GC pause.

If we defer too many cards, the refinement will not make much progress, and the work goes into the GC pause.

> So taking an extreme example, if a thread is blocked for a few minutes
> (or equivalently, but less likely, is in native) then you are concerned
> that many of these epoch-sync async ops will accumulate, and that could
> cause memory pressure and slowdown the thread's return to Java. I can
> see that is a concern. But the first thought I had in relation to this
> problem was that perhaps we need to introduce the notion of coalescable
> operations: if all epoch-sync operations are equivalent then you only
> need at most one to get enqueued. Of course then we have to scan the
> queue for an existing occurrence. But that seems more general a solution
> to unbounded deferred operations than introducing a way to "skip"
> blocked threads.

Yes, if the epoch sync protocol stays with using handshake, it would ideally need such a coalescable handshake op. However, the suggested arm-the-poll-only approach can replace handshakes for the epoch sync protocol, and is coalescable by itself. If the target's poll is already armed, arming it again doesn't do anything. This approach also avoids allocating any `HandshakeClosure` or `HandshakeOperation` altogether.

There is the theoretical problem of having unbounded deferred cards. It is not a concern in practice because deferred cards are extremely rare, and GC pauses happen frequently which free up those deferred cards. Also I think G1DirtyCardQueue and SATBMarkQueue are already unbounded, and deferred cards are much fewer than them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From david.holmes at oracle.com  Thu May 20 07:43:09 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 May 2021 17:43:09 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <SAttDGHN5cKh4gXqNuNCRbx6y8QvOo7J8QLavc_AbsA=.4168e46b-5875-4f93-aa82-15fb6aeec9c3@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
 <SAttDGHN5cKh4gXqNuNCRbx6y8QvOo7J8QLavc_AbsA=.4168e46b-5875-4f93-aa82-15fb6aeec9c3@github.com>
Message-ID: <6ddf9a52-f4ef-8def-4f91-51ac1d499e38@oracle.com>

On 20/05/2021 5:33 pm, Man Cao wrote:
> On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:
> 
>>> Hi all,
>>>
>>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>>>
>>> -Man
>>
>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Added missing deallocation and renamed "remote" to "non-self".
> 
> Thanks again. Yes, the discussion here is really helpful.
> 
>> But I'm not at all convinced that there may not be any ordering
>> dependencies ever. Maybe it is a misuse, but how hard will be it be to
>> spot this misuse, or debug it ? (rhetorical question)
> 
> Do we agree that for this change we don't need to preserve the order yet? Preserving the order probably needs a separate RFE and more discussion. It should be considered again if there are more async non-self executable ops in the future.

Yes agreed.

>> If the deferred op is a no-op then I'm not sure how this creates work
>> for a later GC pause. Assume all the Java threads are executing in
>> native and stay there for a long time - why should that impact the GC's
>> work?
> 
> The actual work is to refine the dirty card. There are 3 major steps to refine a dirty card with G1 epoch sync:
> 1. Clean the card
> 2. Do the epoch sync protocol with all Java threads
> 3. If the epoch sync is successful, refine the cleaned card. If unsuccessful, defer the card to be checked and refined later, or to be processed in the next incremental GC pause.
> 
> If we defer too many cards, the refinement will not make much progress, and the work goes into the GC pause.

Still not clear why this is necessary. The target thread is just as 
blocked or in native during a GC pause safepoint, as it is during a 
handshake. So if the GC can process them in one case surely it can do 
both. ??

>> So taking an extreme example, if a thread is blocked for a few minutes
>> (or equivalently, but less likely, is in native) then you are concerned
>> that many of these epoch-sync async ops will accumulate, and that could
>> cause memory pressure and slowdown the thread's return to Java. I can
>> see that is a concern. But the first thought I had in relation to this
>> problem was that perhaps we need to introduce the notion of coalescable
>> operations: if all epoch-sync operations are equivalent then you only
>> need at most one to get enqueued. Of course then we have to scan the
>> queue for an existing occurrence. But that seems more general a solution
>> to unbounded deferred operations than introducing a way to "skip"
>> blocked threads.
> 
> Yes, if the epoch sync protocol stays with using handshake, it would ideally need such a coalescable handshake op. However, the suggested arm-the-poll-only approach can replace handshakes for the epoch sync protocol, and is coalescable by itself. If the target's poll is already armed, arming it again doesn't do anything. This approach also avoids allocating any `HandshakeClosure` or `HandshakeOperation` altogether.

I'm not clear how arm-the-poll-only gets exposed as an API, but in 
principal I can see it is just an optimisation for an empty handshake op.

Thanks,
David
-----

> There is the theoretical problem of having unbounded deferred cards. It is not a concern in practice because deferred cards are extremely rare, and GC pauses happen frequently which free up those deferred cards. Also I think G1DirtyCardQueue and SATBMarkQueue are already unbounded, and deferred cards are much fewer than them.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From simonis at openjdk.java.net  Thu May 20 07:45:39 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 20 May 2021 07:45:39 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <7WA_YIFz-JUVhJIUYWJtOVSrkDigY7LcASxoWDAcrXs=.4b6eaf0f-229a-40cd-b1df-3a4755619176@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
 <7WA_YIFz-JUVhJIUYWJtOVSrkDigY7LcASxoWDAcrXs=.4b6eaf0f-229a-40cd-b1df-3a4755619176@github.com>
Message-ID: <nphthGQQaRlTk_GrvYVsJu31DcaNrMeVGa_PopzHH4U=.0fd830c6-9a12-4ca2-828a-f5675c6cb655@github.com>

On Wed, 19 May 2021 18:03:09 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 180:
>> 
>>> 178:       // over all logging I/O.
>>> 179:       for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
>>> 180:         ts->wait_until_no_readers();
>> 
>> This loop is the only thing I'm not understanding in this whole PR but that doesn't mean it is wrong (it's probably just caused by my limited understanding of UL).
>> So why do we have to wait here until "there are no more readers" and what does that actually means? Is this necessary to prevent mixing log messages which have been printed before async logging was started?
>
> I would like to consolidate "exclusively". Once async logging takes over, we guarantee that no synchronous logsite is writing files in concurrency.  If we guarantee that, we can avoid FileLocker() because only AsyncLog Thread writes files. 
> 
> Fence isn't enough here. fence can only guarantee that logsites 'after' the fence use async logging.  It's possible that there are on-going synchronous logging. 
> 
> This is a RCU trick of Unified logging.  RCU is kind of synchronization biased to multiple readers. `LogOutputList::Iterator` actually embeds an atomic counter.
> ts->wait_until_no_readers() waits until all readers finish. It means that all synchronous write have done. 
> 
> here is how synchronous log writes. Iterator increases to zero when the loop is done. 
>  
> 
> 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);
>   }
> }```

Thanks for the explanation. I assume you meant that the `Iterator` **de**creases the readers to zero when the loop is done. But I think I got it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From njian at openjdk.java.net  Thu May 20 07:48:09 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 20 May 2021 07:48:09 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support
Message-ID: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>

This is the integration of current SVE work done in panama-vector/vectorIntrinscs, which includes:

1. Code generation for Vector API c2 IR nodes with SVE.
2. Non-max vector size support with SVE, e.g. using *128Vector (and *64Vector) APIs on 256-bit SVE environment could also generate optimized SVE instructions with predicate feature.
3. Some more SVE assemblers (and tests) used by the codegen part.

Test: tier1-3 with vector api test cases passed on 512-bit SVE hardware with MaxVectorSize=16/32/64.

Note: our original plan was making this work part of JEP 414 Vector API (Second Incubator) [1], but we realized that it's now close to 17 release cycle and the JEP process may take time. Adding more features could delay the whole review process for the JEP. So we separate this work out as a standalone patch.

[1] http://openjdk.java.net/jeps/414

-------------

Commit messages:
 - 8267356: AArch64: Vector API SVE codegen support

Changes: https://git.openjdk.java.net/jdk/pull/4122/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4122&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267356
  Stats: 5486 lines in 10 files changed: 4556 ins; 144 del; 786 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4122.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4122/head:pull/4122

PR: https://git.openjdk.java.net/jdk/pull/4122

From aph at redhat.com  Thu May 20 08:15:02 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 20 May 2021 09:15:02 +0100
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support
In-Reply-To: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
Message-ID: <996105ee-d838-79ad-7536-590a814bf8d6@redhat.com>

On 5/20/21 8:48 AM, Ningsheng Jian wrote:
> Note: our original plan was making this work part of JEP 414 Vector API (Second Incubator) [1], but we realized that it's now close to 17 release cycle and the JEP process may take time. Adding more features could delay the whole review process for the JEP. So we separate this work out as a standalone patch.

Does this code do anything in the JDK itself? Can it be tested outside
the incubator project?

-- 
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 xliu at openjdk.java.net  Thu May 20 08:20:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 08:20:54 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
Message-ID: <vWWcuyktIe7yW2-ctENr8nRSVYbAeA_qUUAT--8MhG4=.c7e5f42e-8fdd-40b8-b987-804e2ca4f74c@github.com>

On Wed, 19 May 2021 12:49:30 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement the new discard policy: drop the incoming message.
>>   
>>   This patch also fix a bug. meta messages append to the temp logs instead
>>   of directly calling output->write_blocking(). This guranatees logsites are non-blocking.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 129:
> 
>> 127:   // Along with logs destruction, all procceeded messages are deleted.
>> 128:   //
>> 129:   // the atomic operation 'move' is done in O(1). All I/O jobs are done without lock.
> 
> Start with uppercase letter. Replace 'move' by 'pop_all()' because at this point it in?s not obvious that 'pop_all()' eventually calls 'LinkedList::move()'.
> What do you mean with "atomic" here? Maybe better remove?

` _buffer.pop_all(&logs)` is placed in 'critical region' on purpose. 
It's because logsites may be enqueuing concurrently. that's why I need to use a lock to protect _buffer. 
I see 'atomic' is inappropriate in the context. I will remove it.

> src/hotspot/share/logging/logAsyncWriter.cpp line 175:
> 
>> 173:     if (self->_state == ThreadState::Initialized) {
>> 174:       Atomic::release_store_fence(&AsyncLogWriter::_instance, self);
>> 175:       // all readers of _instance after fence see NULL,
> 
> Please start sentences with uppercase letter.
> 
> I don't understand this? Wouldn't all readers of '_instance' see 'self' *after* it was stored there with 'Atomic::release_store_fence()`? Or do you wanted to say *before* the fence here?

My fault.  I mean "All readers of _instance after the fence see non-NULL".

> src/hotspot/share/logging/logAsyncWriter.hpp line 89:
> 
>> 87: 
>> 88:   LinkedListNode<E>* head() const {
>> 89:     return static_cast<const LinkedList<E>* >(this)->head();
> 
> Why not simply `return this->_head`?

yes, it works!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 20 08:33:36 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 08:33:36 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <nphthGQQaRlTk_GrvYVsJu31DcaNrMeVGa_PopzHH4U=.0fd830c6-9a12-4ca2-828a-f5675c6cb655@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
 <7WA_YIFz-JUVhJIUYWJtOVSrkDigY7LcASxoWDAcrXs=.4b6eaf0f-229a-40cd-b1df-3a4755619176@github.com>
 <nphthGQQaRlTk_GrvYVsJu31DcaNrMeVGa_PopzHH4U=.0fd830c6-9a12-4ca2-828a-f5675c6cb655@github.com>
Message-ID: <SKs-G3EHi67-OObYAjCv_Rb7o33Z5aSBKIjHg-p6ahg=.1838e224-7f02-40df-8a5d-d678b3942c5e@github.com>

On Thu, 20 May 2021 07:42:43 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> I would like to consolidate "exclusively". Once async logging takes over, we guarantee that no synchronous logsite is writing files in concurrency.  If we guarantee that, we can avoid FileLocker() because only AsyncLog Thread writes files. 
>> 
>> Fence isn't enough here. fence can only guarantee that logsites 'after' the fence use async logging.  It's possible that there are on-going synchronous logging. 
>> 
>> This is a RCU trick of Unified logging.  RCU is kind of synchronization biased to multiple readers. `LogOutputList::Iterator` actually embeds an atomic counter.
>> ts->wait_until_no_readers() waits until all readers finish. It means that all synchronous write have done. 
>> 
>> here is how synchronous log writes. Iterator increases to zero when the loop is done. 
>>  
>> 
>> 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);
>>   }
>> }```
>
> Thanks for the explanation. I assume you meant that the `Iterator` **de**creases the readers to zero when the loop is done. But I think I got it now.

Yes, the scope of 'it' is defined inside the 'for' construct.  Once control flow exists the loop, 
the dtor of Iterator will automatically be invoked. When all pending synchronous logsites have completed,  all RCU counters of OutputList objects restore to zero.  It means there's no on-going 'reader'. 
 


    ~Iterator() {
      _list->decrease_readers();
    }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 20 08:33:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 08:33:37 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
Message-ID: <ZuiVnmj3lsVIzw2CpH5QQ7rKZx95QDI4VXOzUR4CHk8=.631d5639-e2f6-47e8-b891-82605e081ec3@github.com>

On Wed, 19 May 2021 13:14:03 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement the new discard policy: drop the incoming message.
>>   
>>   This patch also fix a bug. meta messages append to the temp logs instead
>>   of directly calling output->write_blocking(). This guranatees logsites are non-blocking.
>
> src/hotspot/share/runtime/thread.hpp line 106:
> 
>> 104: //     - WatcherThread
>> 105: //     - JfrThreadSampler
>> 106: //     - LogAsyncFlusher
> 
> I think this should be `AsyncLogWriter`

yes. thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From rehn at openjdk.java.net  Thu May 20 08:53:35 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 08:53:35 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <emKtlTBHKMVMAbAk1g2bFOhaUxoA-EqIc3jy_YEsMuU=.19a3896b-d00b-4de6-b449-9e23d81b35ec@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

"The goal is to support asynchronous handshake with all threads for JDK-8236485, and skipping threads that are blocked, without entering a safepoint in the requesting thread."

This line is just confusing, the requesting thread only enters a safepoint if it's a JavaThread.

- You don't need to skip blocked/native thread, those handshakes are finished really quickly on first iteration.
- If VM thread is busy doing starting safepoint, you can skip your epoch, since you just got it free via the safepoint.
  - Save the current safepoint counter and store it in the VM op.
  - Check that safepoint counter vs current counter in the VM ops doit_prologue()
  - If they do not match all threads have emitted the barrier. 

- All JavaThreads will safepoint before they perform any handshakes.
- If there is a safepoint, we should perform it was quick as possible, otherwise it will take longer for them to perform handshakes. 
- G1 concurrent threads are stopped before the safepoint: 

void G1CollectedHeap::safepoint_synchronize_begin() {
  SuspendibleThreadSet::synchronize();
}  



Not sure if this epoch sync is run by a thread part of SuspendibleThreadSet or not, but:
If it is; it is just prolonging the time to safepoint, which is a free epoch, thus finishing the epoch just wastes CPU.
If it is not; it is just hurting it's own performance, since handshakes are performed _after_ the safepoint.

So I do not see any reason why you can't use a synchronous handshakes.

If a Java thread does not do it's handshake in timely manner, there are generally be two issues:
- You don't have enough CPU, so the thread is not running. Using more CPU will just hurt in this case, so yielding is the correct thing todo.
- We are allocating and zeroing a large array, which is a GC issue. (fixed in ZGC)

If you have seem another case where you think a synchronous handshake takes to long, please let me know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From xliu at openjdk.java.net  Thu May 20 08:55:42 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 08:55:42 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v16]
In-Reply-To: <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <azdbmu8MYOg__qky217PnB0QARBugb9CrHM3VohTC5I=.26f97253-09f8-4b06-a123-4e0fbdf815ac@github.com>
 <SGKfPcEzK9-DAcp0NC3QWSKJIdH3DBpCKqAq0NAdYxM=.3dc66b44-bb3b-4ab7-ac57-25358259be22@github.com>
Message-ID: <Lj-8zRc3QFdV1mmXgtm1ifsqmbMk6qT4ragnWjCBSRk=.b7eecbe8-1b17-4bf8-9bb6-41d849fa6c12@github.com>

On Wed, 19 May 2021 13:16:44 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement the new discard policy: drop the incoming message.
>>   
>>   This patch also fix a bug. meta messages append to the temp logs instead
>>   of directly calling output->write_blocking(). This guranatees logsites are non-blocking.
>
> test/hotspot/gtest/logging/logTestUtils.inline.hpp line 24:
> 
>> 22:  */
>> 23: 
>> 24: #include "jvm.h"
> 
> Why do you need this extra include if there are no other changes in this file?

logTestUtils.inline.hpp uses 'jio_snprintf', which is declared in jvm_io.h. 
I found that gtests included jvm.h ahead of include "logTestUtils.inline.hpp". 
I will define in the the way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 20 09:08:04 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 09:08:04 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Update according to reviewer's feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/be83aafd..348edfc0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=15-16

  Stats: 37 lines in 9 files changed: 1 ins; 13 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From jiefu at openjdk.java.net  Thu May 20 09:21:56 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 20 May 2021 09:21:56 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow [v4]
In-Reply-To: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
Message-ID: <5HjBGAoSyOYzHJcb5PB0KdE-NqSPrQt4pDRHYGyrtDE=.1c967ae4-38c3-4d64-8577-ac08098c9e2c@github.com>

> Hi all,
> 
> This is a follow-up of JDK-8260046.
> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
> Let's fix it
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  cpuinfo_segv should not be triaged as execution protection violation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4044/files
  - new: https://git.openjdk.java.net/jdk/pull/4044/files/812f3c5a..f3d85e54

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4044&range=02-03

  Stats: 5 lines in 3 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4044.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4044/head:pull/4044

PR: https://git.openjdk.java.net/jdk/pull/4044

From ningsheng.jian at arm.com  Thu May 20 10:42:44 2021
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Thu, 20 May 2021 18:42:44 +0800
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support
In-Reply-To: <996105ee-d838-79ad-7536-590a814bf8d6@redhat.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <996105ee-d838-79ad-7536-590a814bf8d6@redhat.com>
Message-ID: <3661bb09-5de6-8b8b-1d38-da94a2731cf4@arm.com>

Hi Andrew,

On 5/20/21 4:15 PM, Andrew Haley wrote:
> On 5/20/21 8:48 AM, Ningsheng Jian wrote:
>> Note: our original plan was making this work part of JEP 414 Vector API (Second Incubator) [1], but we realized that it's now close to 17 release cycle and the JEP process may take time. Adding more features could delay the whole review process for the JEP. So we separate this work out as a standalone patch.
> 
> Does this code do anything in the JDK itself? Can it be tested outside
> the incubator project?
> 

Without this patch, running current Vector API code, landed in jdk16, on 
SVE systems, will simply fallback to the API's java implementation 
without intrinsification.

This patch has been tested with existing Vector API code in current 
jdk/jdk project, with expected SVE code generated.


Thanks,
Ningsheng

From jiefu at openjdk.java.net  Thu May 20 11:27:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 20 May 2021 11:27:33 GMT
Subject: RFR: 8267213: assert(left >= right) failed: avoid underflow
In-Reply-To: <a299142c-6d86-3c70-3420-20a76b2b11d7@oracle.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <a299142c-6d86-3c70-3420-20a76b2b11d7@oracle.com>
Message-ID: <-3WeGT4Aeh_4wqf4chZzoAhszgw8IvJavBOKbOVFVOA=.d55a8039-4a63-44d8-bdd6-5585c3cf4787@github.com>

On Tue, 18 May 2021 07:10:17 GMT, David Holmes <david.holmes at oracle.com> wrote:

> Have you analysed the original crash to check what the actual pc and
> addr values were?

Hi @dholmes-ora ,

After more investigation, I believe this is a signal handling bug.

In this case, cpuinfo_segv is incorrectly triaged as execution protection violation on Linux/x86_32.

During VM initialization, cpuinfo_segv [1] will be triggered (by accessing addr=0) on purpose.

#0  VM_Version::get_processor_features () at /home/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:630
#1  0xf720cc21 in VM_Version::initialize () at /home/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:1890
#2  0xf7206d85 in VM_Version_init () at /home/jdk/src/hotspot/share/runtime/vm_version.cpp:32
#3  0xf6b72e4f in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:119
#4  0xf71500c6 in Threads::create_vm (args=0xf621a26c, canTryAgain=0xf621a1d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2854
#5  0xf6c6b167 in JNI_CreateJavaVM_inner (vm=0xf621a2bc, penv=0xf621a2c0, args=0xf621a26c) at /home/jdk/src/hotspot/share/prims/jni.cpp:3592
#6  0xf6c6b35c in JNI_CreateJavaVM (vm=0xf621a2bc, penv=0xf621a2c0, args=0xf621a26c) at /home/jdk/src/hotspot/share/prims/jni.cpp:3680
#7  0xf7fbe61f in InitializeJVM (pvm=0xf621a2bc, penv=0xf621a2c0, ifn=0xf621a300) at /home/jdk/src/java.base/share/native/libjli/java.c:1539
#8  0xf7fbb283 in JavaMain (_args=0xffffa484) at /home/jdk/src/java.base/share/native/libjli/java.c:415
#9  0xf7fc1bed in ThreadJavaMain (args=0xffffa484) at /home/jdk/src/java.base/unix/native/libjli/java_md.c:651
#10 0xf7d983bd in start_thread (arg=0xf621ab40) at pthread_create.c:463


The VM can recognizes it as cpuinfo_segv [2] here and assigned the stub.
But unfortunately, it's re-triaged as execution protection violation on x86_32 when UnguardOnExecutionViolation > 0, which shouldn't happen.

To avoid this kind of false-positive, one more condition `stub == NULL` is added.

Note: we don't need to change windows since there is a special signal for this condition [3].

Thanks.
Best regards,
Jie


[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L466
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L246
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L2449

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From akozlov at openjdk.java.net  Thu May 20 11:51:32 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 20 May 2021 11:51:32 GMT
Subject: RFR: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
Message-ID: <xOffKpMrH_FR2d3VanRf7BZdJpkmocsg98QyOkLBv3M=.5185c0e3-3aff-4da7-abbc-2b5be5af15e1@github.com>

On Wed, 19 May 2021 12:54:03 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this patch for call_VM_Base routine.
> it's expected there the LR is callee-saved register, but it's not on aarch64.
> when InterpreterRuntime::throw_pending_exception is tail-call optimized,
> the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR.
> It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build.

The change looks good to me, but I'm not a formal reviewer. 

AArch64's StubRoutines::forward_exception_entry below expects LR to point to after the runtime call. Usually LR is preserved by the runtime callee, but this is not required by the ABI [1]. So we need to restore LR after the call.

[1] https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d55170c563c3c7940134089176746/aapcs64/aapcs64.rst#general-purpose-registers

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 686:

> 684:   ldr(lr, Address(rthread,
> 685:                             JavaThread::frame_anchor_offset()
> 686:                             + JavaFrameAnchor::last_Java_pc_offset()));

`ldr(lr, Address(rthread, JavaThread::last_Java_pc_offset()))`? Same meaning, but shorter.

-------------

Marked as reviewed by akozlov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4115

From stefank at openjdk.java.net  Thu May 20 12:03:00 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 20 May 2021 12:03:00 GMT
Subject: RFR: 8267464: Circular-dependency resiliant inline headers
Message-ID: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>

I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.

This is a small, contrived example to show the problem:

// a.hpp
#pragma once

void a1();
void a2();


// a.inline.hpp
#pragma once

#include "a.hpp"
#include "b.inline.hpp"

inline void a1() {
  b1();
}

inline void a2() {
}


// b.hpp
#pragma once

void b1();
void b2();


// b.inline.hpp
#pragma once

#include "a.inline.hpp"
#include "b.hpp"

inline void b1() {
}

inline void b2() {
  a1();
}

The following code compiles fine:

// a.cpp
#include "a.inline.hpp"

int main() {
  a1();

  return 0;
}

But the following:

// b.cpp
#include "b.inline.hpp"

int main() {
  b1();

  return 0;
}


fails with the this error message:

In file included from b.inline.hpp:3,
                 from b.cpp:1:
a.inline.hpp: In function ?void a1()?:
a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??

We can see the problem with g++ -E:

# 1 "a.inline.hpp" 1
# 1 "a.hpp" 1

void a1();
void a2();

# 4 "a.inline.hpp" 2

inline void a1() {
  b1();
}

inline void a2() {
}

# 4 "b.inline.hpp" 2
# 1 "b.hpp" 1

void b1();
void b2();

# 5 "b.inline.hpp" 2

inline void b1() {
}

inline void b2() {
  a1();
}

# 2 "b.cpp" 2

int main() {
  b1();

  return 0;
}


b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().

This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.

I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.

In the example above, b.inline.hpp would become:

// b.inline.hpp
#pragma once

#include "b.hpp"
#include "a.inline.hpp"

inline void b1() {
}

inline void b2() {
  a1();
}

and now both a.cpp and b.cpp compiles. The generated output now looks like this:

# 1 "b.inline.hpp" 1
# 1 "b.hpp" 1

void b1();
void b2();

# 4 "b.inline.hpp" 2
# 1 "a.inline.hpp" 1

# 1 "a.hpp" 1

void a1();
void a2();

# 4 "a.inline.hpp" 2

inline void a1() {
  b1();
}

inline void a2() {
}

# 5 "b.inline.hpp" 2

inline void b1() {
}

inline void b2() {
  a1();
}

# 2 "b.cpp" 2

int main() {
  b1();

  return 0;
}

The declarations come first, and the compiler is happy. 

An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.

Some notes about this patch:
1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.

What do you think?

-------------

Commit messages:
 - 8267464: Circular-dependency resiliant inline headers

Changes: https://git.openjdk.java.net/jdk/pull/4127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267464
  Stats: 459 lines in 224 files changed: 350 ins; 104 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From tschatzl at openjdk.java.net  Thu May 20 12:51:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 20 May 2021 12:51:39 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets
Message-ID: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>

Hi all,

  can I have reviews for this change that significantly refactors the remembered set for more scalability.

 The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.

Over time many problems with performance and in particular memory usage have been observed:

* adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).

* there is a substantial memory overhead for managing the data structures: examples are
    * using separate (hash) tables for the three different types of card containers
    * there is significant unnecessary preallocation of memory for some of the card set containers
    * Containers store redundant information

* inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.

* inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.

* (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.

* the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.

The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.

Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).

This change is effectively a rewrite of the Java heap card based part of a region's remembered set.

This initial fully working change can be roughly described with the following properties:

* use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.

* memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.

* there are now four different container types and one meta-container type. These four actual containers are:
  * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
  * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
  * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
  * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
  * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.

* care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.

In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.

Testing: tier1-8 many times, manual and automated perf testing

-------------

Commit messages:
 - Fix 32 bit platforms after premature optimization, implement 64 bit Atomic::sub() via cmpxchg-loop
 - Trailing whitespace fixes
 - Remove unnecessary changes
 - Initial implementation

Changes: https://git.openjdk.java.net/jdk/pull/4116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8017163
  Stats: 6097 lines in 66 files changed: 4563 ins; 1320 del; 214 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4116/head:pull/4116

PR: https://git.openjdk.java.net/jdk/pull/4116

From mcimadamore at openjdk.java.net  Thu May 20 13:05:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:05:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <ni5lwlji8S4j3myGCkUh2auMqtOSGUZZrM3rSHrK8y0=.6a9c125a-928e-4f03-bf64-656918d6bc32@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <ni5lwlji8S4j3myGCkUh2auMqtOSGUZZrM3rSHrK8y0=.6a9c125a-928e-4f03-bf64-656918d6bc32@github.com>
Message-ID: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>

On Thu, 20 May 2021 13:00:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore 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 35 additional commits since the last revision:
> 
>  - Add sealed modifiers in morally sealed API interfaces
>  - Merge branch 'master' into JEP-412
>  - Fix VaList test
>    Remove unused code in Utils
>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>    
>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Merge branch 'master' into JEP-412
>  - Fix issue with bounded arena allocator
>  - Rename is_entry_blob to is_optimized_entry_blob
>    Rename as_entry_blob to as_optimized_entry_blob
>    Fix misc typos and indentation issues
>  - Take care of remaining references to "Panama"
>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>    * Replace EntryBlob with OptimizedEntryBlob
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/629f67e6...e927c235

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200:

> 198:  * Implementations of this interface are immutable, thread-safe and <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>.
> 199:  */
> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout {

In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu May 20 13:05:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:05:22 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <ni5lwlji8S4j3myGCkUh2auMqtOSGUZZrM3rSHrK8y0=.6a9c125a-928e-4f03-bf64-656918d6bc32@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore 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 35 additional commits since the last revision:

 - Add sealed modifiers in morally sealed API interfaces
 - Merge branch 'master' into JEP-412
 - Fix VaList test
   Remove unused code in Utils
 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/788875f9...e927c235

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f5668ffc..e927c235

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22-23

  Stats: 7087 lines in 360 files changed: 4302 ins; 1796 del; 989 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu May 20 13:12:09 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:12:09 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <ni5lwlji8S4j3myGCkUh2auMqtOSGUZZrM3rSHrK8y0=.6a9c125a-928e-4f03-bf64-656918d6bc32@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <ni5lwlji8S4j3myGCkUh2auMqtOSGUZZrM3rSHrK8y0=.6a9c125a-928e-4f03-bf64-656918d6bc32@github.com>
Message-ID: <9PaAroygCBAEwYmF4lNFzy46QKSPJsET65dXf6XQs18=.9059eafa-0dae-4a6c-ab12-461bb6456b92@github.com>

On Thu, 20 May 2021 13:05:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore 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 35 additional commits since the last revision:
> 
>  - Add sealed modifiers in morally sealed API interfaces
>  - Merge branch 'master' into JEP-412
>  - Fix VaList test
>    Remove unused code in Utils
>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>    
>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Merge branch 'master' into JEP-412
>  - Fix issue with bounded arena allocator
>  - Rename is_entry_blob to is_optimized_entry_blob
>    Rename as_entry_blob to as_optimized_entry_blob
>    Fix misc typos and indentation issues
>  - Take care of remaining references to "Panama"
>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>    * Replace EntryBlob with OptimizedEntryBlob
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/354e6edf...e927c235

Latest javadoc:
http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/javadoc/jdk/incubator/foreign/package-summary.html
Latest specdiff:
http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/specdiff/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From jvernee at openjdk.java.net  Thu May 20 13:12:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 20 May 2021 13:12:26 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <ni5lwlji8S4j3myGCkUh2auMqtOSGUZZrM3rSHrK8y0=.6a9c125a-928e-4f03-bf64-656918d6bc32@github.com>
 <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>
Message-ID: <dyq1pZdlk33sqCdlVUrWjPFb6Wv3Uukd23i6mzJFjgE=.0c54c602-ddbe-4ea8-819e-38428a3c7ffd@github.com>

On Thu, 20 May 2021 13:00:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore 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 35 additional commits since the last revision:
>> 
>>  - Add sealed modifiers in morally sealed API interfaces
>>  - Merge branch 'master' into JEP-412
>>  - Fix VaList test
>>    Remove unused code in Utils
>>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>>    
>>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>>  - Merge branch 'master' into JEP-412
>>  - Fix issue with bounded arena allocator
>>  - Rename is_entry_blob to is_optimized_entry_blob
>>    Rename as_entry_blob to as_optimized_entry_blob
>>    Fix misc typos and indentation issues
>>  - Take care of remaining references to "Panama"
>>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>>    * Replace EntryBlob with OptimizedEntryBlob
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/26a8cf83...e927c235
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200:
> 
>> 198:  * Implementations of this interface are immutable, thread-safe and <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>.
>> 199:  */
>> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout {
> 
> In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc.

At least the internal class name is hidden in the javadoc:
![image](https://user-images.githubusercontent.com/5962029/118983890-37042080-b97d-11eb-9ee0-ae5d5db5cd7e.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From aph at openjdk.java.net  Thu May 20 13:18:30 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 20 May 2021 13:18:30 GMT
Subject: RFR: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
Message-ID: <FKttcSuxPc1_Xm4DIr4w5BGeoWeOw-L7v6hFOTsDPTw=.5aa6c010-f028-4c30-91e0-190381604f4e@github.com>

On Wed, 19 May 2021 12:54:03 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this patch for call_VM_Base routine.
> it's expected there the LR is callee-saved register, but it's not on aarch64.
> when InterpreterRuntime::throw_pending_exception is tail-call optimized,
> the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR.
> It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 687:

> 685:                             JavaThread::frame_anchor_offset()
> 686:                             + JavaFrameAnchor::last_Java_pc_offset()));
> 687: 

Is this any different from `adr(lr, l)` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4115

From simonis at openjdk.java.net  Thu May 20 13:51:45 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 20 May 2021 13:51:45 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <QTz1pLr-QDcBRudu56GUyixc0GCbfFAdqe0wJmfN58Q=.9a7e6afd-e633-4c80-935c-226c0e8c5659@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

Thanks Xin!

Looks good to me now.

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From stuefe at openjdk.java.net  Thu May 20 14:03:42 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 20 May 2021 14:03:42 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <NCbHsmGqySMeNLQW58Od2qGXrgTQqBXvtvQhZzX5DA8=.5931a3a2-3df4-46fe-951b-20a9505eb9e0@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

Hi Xin,

Looks good to me too. Ship it.

..Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From stuefe at openjdk.java.net  Thu May 20 14:29:38 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 20 May 2021 14:29:38 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
 <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>
 <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>
Message-ID: <uZoM_3zqshPyIf_8wjA-NzTFkNbZx4lM76yf8KfzJVE=.6166d3f9-9a23-4202-9c41-cffd4e3a7bfb@github.com>

On Fri, 14 May 2021 14:38:11 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Hi,
>> 
>> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java. 
>> 
>> #
>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
>> #  assert(div != 0) failed: lcm requires positive arguments
>> #
>> 
>> 
>> Stack:
>> 
>> 
>> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
>> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
>> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
>> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
>> 
>> 
>> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?
>
>> Hi,
>> 
>> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java.
>> 
>> ```
>> #
>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
>> #  assert(div != 0) failed: lcm requires positive arguments
>> #
>> ```
>> 
>> Stack:
>> 
>> ```
>> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
>> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
>> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
>> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
>> ```
>> 
>> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?
> 
> Thanks @tstuefe. Taking a look now.

Hi @mgkwill , since I have two weeks of vacations upcoming. 

I am fine with the change in its current form, if you take my suggested change (UseLargePages=0 if no default large page size was found). With my addition, the tests at SAP ran through on all our architectures, I could not spot any errors attributable to this patch. Any follow up issues we have not spotted yet we can fix as followups.

If you have no time, thats fine too; I'll be back second week of june.

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From shade at openjdk.java.net  Thu May 20 14:29:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 20 May 2021 14:29:45 GMT
Subject: Integrated: 8267396: Avoid recording "pc" in unhandled oops detector
 for better performance
In-Reply-To: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>
References: <clfAMZ3nBq6xsoZvMl3n7y0vv07mMDPjoX_7KhiewCY=.b536d13b-5bc7-4472-9793-b99254a1128b@github.com>
Message-ID: <pwp0VWrTywbGwqj6H7zY13-uXcNb875X6U3KQM8ivxY=.0877db8f-1c2c-4977-a77a-4c6b291f4164@github.com>

On Wed, 19 May 2021 12:32:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the rationale in the bug.
> 
> Additional testing:
>  - [x] Known slow test with `-XX:+CheckUnhandledOops`
>  - [x] tier1 with `-XX:+CheckUnhandledOops`

This pull request has now been integrated.

Changeset: f67847f5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f67847f52a306874d1a0d92250f8a556b3af6507
Stats:     11 lines in 3 files changed: 0 ins; 3 del; 8 mod

8267396: Avoid recording "pc" in unhandled oops detector for better performance

Reviewed-by: coleenp, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4114

From mgkwill at openjdk.java.net  Thu May 20 15:08:52 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 20 May 2021 15:08:52 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
 <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>
 <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>
Message-ID: <mNwS0fWQWMpcOzRiDiryRasRXqTlDHVsZz3HfSUrHoc=.d295b0d8-a3f3-4318-bc2f-91c10bad3a89@github.com>

On Fri, 14 May 2021 14:38:11 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Hi,
>> 
>> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java. 
>> 
>> #
>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
>> #  assert(div != 0) failed: lcm requires positive arguments
>> #
>> 
>> 
>> Stack:
>> 
>> 
>> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
>> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
>> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
>> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
>> 
>> 
>> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?
>
>> Hi,
>> 
>> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java.
>> 
>> ```
>> #
>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
>> #  assert(div != 0) failed: lcm requires positive arguments
>> #
>> ```
>> 
>> Stack:
>> 
>> ```
>> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
>> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
>> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
>> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
>> ```
>> 
>> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?
> 
> Thanks @tstuefe. Taking a look now.

> Hi @mgkwill , since I have two weeks of vacations upcoming.
> 
> I am fine with the change in its current form, if you take my suggested change (UseLargePages=0 if no default large page size was found). With my addition, the tests at SAP ran through on all our architectures, I could not spot any errors attributable to this patch. Any follow up issues we have not spotted yet we can fix as followups.
> 
> If you have no time, thats fine too; I'll be back second week of june.
> 
> Cheers, Thomas

@tstuefe Working on an update now. Stay tuned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From vkempik at openjdk.java.net  Thu May 20 15:19:22 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 20 May 2021 15:19:22 GMT
Subject: RFR: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
 [v2]
In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
Message-ID: <zxiigcXboQ1wcJHUXoycL9uyaiu-mJrYfSWrOhJvVKg=.5d73c7bc-017d-43dd-8c69-de3ce5ffd8a0@github.com>

> Please review this patch for call_VM_Base routine.
> it's expected there the LR is callee-saved register, but it's not on aarch64.
> when InterpreterRuntime::throw_pending_exception is tail-call optimized,
> the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR.
> It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build.

Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:

  Update the fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4115/files
  - new: https://git.openjdk.java.net/jdk/pull/4115/files/5b7c4cec..edea0a61

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4115&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4115&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4115/head:pull/4115

PR: https://git.openjdk.java.net/jdk/pull/4115

From vkempik at openjdk.java.net  Thu May 20 15:19:25 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 20 May 2021 15:19:25 GMT
Subject: RFR: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
 [v2]
In-Reply-To: <FKttcSuxPc1_Xm4DIr4w5BGeoWeOw-L7v6hFOTsDPTw=.5aa6c010-f028-4c30-91e0-190381604f4e@github.com>
References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
 <FKttcSuxPc1_Xm4DIr4w5BGeoWeOw-L7v6hFOTsDPTw=.5aa6c010-f028-4c30-91e0-190381604f4e@github.com>
Message-ID: <GEZk76JYTfXVQYPUGTgORuUSNjDrUwWWinN9fx7xjo4=.d854e185-cc87-420a-b02d-fcc8a71b3fef@github.com>

On Thu, 20 May 2021 13:15:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the fix
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 687:
> 
>> 685:                             JavaThread::frame_anchor_offset()
>> 686:                             + JavaFrameAnchor::last_Java_pc_offset()));
>> 687: 
> 
> Is this any different from `adr(lr, l)` ?

this gives exactly same result, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4115

From mgkwill at openjdk.java.net  Thu May 20 15:19:54 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 20 May 2021 15:19:54 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v38]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <rLiRnniTrPkZ8T-0bLgKcu5I27FBAyfFpREErqRe6OU=.e56d5135-6a31-4d0e-b2fe-77978f28377d@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:

 - Merge branch 'master' into update_hlp
 - kstefanj review comments
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Reuse flags & p vars, fix enclose
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Check smaller LP sizes in setup
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Check large pages =< _large_page_size
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Review comments 5_12
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Remove reserve_memory_special_huge_tlbfs mods except assert
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Merge branch 'master' into update_hlp
 - Merge branch 'master' into update_hlp
 - ... and 50 more: https://git.openjdk.java.net/jdk/compare/b7b6acd9...aa686775

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1153/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=37
  Stats: 151 lines in 3 files changed: 91 ins; 39 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153

PR: https://git.openjdk.java.net/jdk/pull/1153

From aph at openjdk.java.net  Thu May 20 15:36:37 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 20 May 2021 15:36:37 GMT
Subject: RFR: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
 [v2]
In-Reply-To: <zxiigcXboQ1wcJHUXoycL9uyaiu-mJrYfSWrOhJvVKg=.5d73c7bc-017d-43dd-8c69-de3ce5ffd8a0@github.com>
References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
 <zxiigcXboQ1wcJHUXoycL9uyaiu-mJrYfSWrOhJvVKg=.5d73c7bc-017d-43dd-8c69-de3ce5ffd8a0@github.com>
Message-ID: <mYoZdpenr3_nDRVotf4pNpaMqu16US216wuZYJsPE9Y=.401c886d-acc6-4818-acd5-0c8cbde74d96@github.com>

On Thu, 20 May 2021 15:19:22 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this patch for call_VM_Base routine.
>> it's expected there the LR is callee-saved register, but it's not on aarch64.
>> when InterpreterRuntime::throw_pending_exception is tail-call optimized,
>> the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR.
>> It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the fix

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4115

From mgkwill at openjdk.java.net  Thu May 20 15:47:33 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 20 May 2021 15:47:33 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v39]
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  tstuefe review
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1153/files
  - new: https://git.openjdk.java.net/jdk/pull/1153/files/aa686775..1a487dea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=38
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=37-38

  Stats: 11 lines in 1 file changed: 8 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153

PR: https://git.openjdk.java.net/jdk/pull/1153

From mgkwill at openjdk.java.net  Thu May 20 15:47:34 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 20 May 2021 15:47:34 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <mNwS0fWQWMpcOzRiDiryRasRXqTlDHVsZz3HfSUrHoc=.d295b0d8-a3f3-4318-bc2f-91c10bad3a89@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
 <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>
 <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>
 <mNwS0fWQWMpcOzRiDiryRasRXqTlDHVsZz3HfSUrHoc=.d295b0d8-a3f3-4318-bc2f-91c10bad3a89@github.com>
Message-ID: <MZucMP-tNu3PV_SChUrlSt6hPQ0bYNe_GDfkANW8HT0=.2e487e7c-f70f-4d67-885f-bd8b2ff5c96e@github.com>

On Thu, 20 May 2021 15:05:34 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

> > Hi @mgkwill , since I have two weeks of vacations upcoming.
> > I am fine with the change in its current form, if you take my suggested change (UseLargePages=0 if no default large page size was found). With my addition, the tests at SAP ran through on all our architectures, I could not spot any errors attributable to this patch. Any follow up issues we have not spotted yet we can fix as followups.
> > If you have no time, thats fine too; I'll be back second week of june.
> > Cheers, Thomas
> 
> @tstuefe Working on an update now. Stay tuned.

@tstuefe incorporated your suggestion with @kstefanj updates.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From vkempik at openjdk.java.net  Thu May 20 15:49:34 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 20 May 2021 15:49:34 GMT
Subject: Integrated: 8267235: [macos_aarch64]
 InterpreterRuntime::throw_pending_exception messing up LR results in crash
In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com>
Message-ID: <v6Bgkbw0W6ogIA4KhwQiT1EM7lxNzJRDhlvuUcg2i1I=.851e5cff-8222-41be-854c-48aea0fe2db8@github.com>

On Wed, 19 May 2021 12:54:03 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this patch for call_VM_Base routine.
> it's expected there the LR is callee-saved register, but it's not on aarch64.
> when InterpreterRuntime::throw_pending_exception is tail-call optimized,
> the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR.
> It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build.

This pull request has now been integrated.

Changeset: ca93399a
Author:    Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ca93399af103384e750dabf3abcc6e8392bcf3f4
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash

Reviewed-by: akozlov, aph

-------------

PR: https://git.openjdk.java.net/jdk/pull/4115

From stuefe at openjdk.java.net  Thu May 20 16:05:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 20 May 2021 16:05:43 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v39]
In-Reply-To: <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>
Message-ID: <uLr0fObYRY7Z7RgZsLmBeUd_ep5lpLMRt4oHMGMrwiM=.fe6a820c-3b97-49a8-a2e2-f5e1933d5725@github.com>

On Thu, 20 May 2021 15:47:33 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tstuefe review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Looks good to me now. 

Great job, @mgkwill , thanks a lot for sticking it out and having the patience to work for a good solution! I think the resulting code, including all the preparatory patches by Stefan, looks way better now and is really better to maintain.

Cheers, Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1153

From sjohanss at openjdk.java.net  Thu May 20 16:44:40 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 20 May 2021 16:44:40 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v39]
In-Reply-To: <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>
Message-ID: <N18jHb4YEdMN6o-IeXzq_BhLCAnCZjbcd_UUMdTa_Xo=.f9a581ff-bd34-49a7-afe7-cb4625a4e345@github.com>

On Thu, 20 May 2021 15:47:33 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tstuefe review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Looks good. I want to re-iterate what Thomas said, big thanks for having patience and letting it take time.

I will run this through testing over the night, so hopefully we can integrate this tomorrow. If you like you can integrate now and I will issue the sponsor command tomorrow.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1153

From mgkwill at openjdk.java.net  Thu May 20 17:09:41 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 20 May 2021 17:09:41 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v36]
In-Reply-To: <uZoM_3zqshPyIf_8wjA-NzTFkNbZx4lM76yf8KfzJVE=.6166d3f9-9a23-4202-9c41-cffd4e3a7bfb@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <EJDa0ax1dOABoWGWcowpINiq5QhGIhTbScExnrcemXk=.e208eb9d-d581-45aa-bb52-8889c319bb6a@github.com>
 <aFqGxQroKDtnQKAL1InAOXwCOCp-HVDKaSvQHCt8U8Y=.c0eb6325-c4a0-496a-ad0e-864bc8d0668b@github.com>
 <o3zXV5pRof2fnpdbKfHqhRwmXQW8xl0m06uKITzPwTw=.f40440f1-c38c-4b95-bb14-d9371702d071@github.com>
 <uZoM_3zqshPyIf_8wjA-NzTFkNbZx4lM76yf8KfzJVE=.6166d3f9-9a23-4202-9c41-cffd4e3a7bfb@github.com>
Message-ID: <a5hRh7IP0y_pLfJaVeYqdjenmTbrlJAbVJNeZd3Ev0c=.dec4bece-3b2c-4602-b274-3d9021444212@github.com>

On Thu, 20 May 2021 14:26:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Hi,
>>> 
>>> we see crashes on linux ppc64 with gc/g1/TestLargePageUseForAuxMemory.java.
>>> 
>>> ```
>>> #
>>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64/jdk-dev/src/hotspot/share/utilities/globalDefinitions.cpp:370), pid=44816, tid=44821
>>> #  assert(div != 0) failed: lcm requires positive arguments
>>> #
>>> ```
>>> 
>>> Stack:
>>> 
>>> ```
>>> V  [libjvm.so+0xd22efc]  lcm(unsigned long, unsigned long)+0xdc
>>> V  [libjvm.so+0xcc9430]  GCArguments::compute_heap_alignment()+0x70
>>> V  [libjvm.so+0x490d1c]  Arguments::apply_ergo()+0x7c
>>> V  [libjvm.so+0x186a66c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ec
>>> ```
>>> 
>>> Note that ppc64 has 64k pages. I don't have time to investigate this right now, but maybe you can reproduce the crash by faking a 64k page size in os::vm_page_size()?
>> 
>> Thanks @tstuefe. Taking a look now.
>
> Hi @mgkwill , since I have two weeks of vacations upcoming. 
> 
> I am fine with the change in its current form, if you take my suggested change (UseLargePages=0 if no default large page size was found). With my addition, the tests at SAP ran through on all our architectures, I could not spot any errors attributable to this patch. Any follow up issues we have not spotted yet we can fix as followups.
> 
> If you have no time, thats fine too; I'll be back second week of june.
> 
> Cheers, Thomas

@tstuefe @kstefanj Thank you for helping me get up to speed on contributing to openjdk as a newbie and for all of the review, suggestions and guidance on getting this patch to where it is today. The patch accomplishes the original goal and is leaps and bounds more readable, better implemented and maintainable. Thank you both also for the patches merged, the CSR and all the effort to prepare for this change and make it better.

I'll comment to integrate today, with knowledge that sponsorship is dependent on the testing Stefan is running. 

Thanks again!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From chris at sageembedded.com  Thu May 20 17:13:53 2021
From: chris at sageembedded.com (Chris Cole)
Date: Thu, 20 May 2021 10:13:53 -0700
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
 <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
Message-ID: <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>

Hi Boris,

Thanks for looking into this and your support. See comments below.

On Wed, May 19, 2021 at 2:20 AM Boris Ulasevich
<boris.ulasevich at bell-sw.com> wrote:
>
> Hi Chris,
>
> I agree that the problem is in C1_MacroAssembler::lock_object.

I believe that this issue can be fixed by initializing the displaced
header in either
C1_MacroAssembler::lock_object/SharedRuntime::generate_native_wrapper
or in ObjectSynchronizer::quick_enter with changes provided in
previous email.

I would suggest that where the problem/fix is located depends on what
the "interface contract" is for initializing the displaced header
between JIT inlined code and the monitor enter runtime helper. This
"interface contract" is not documented anywhere so it is defined by
how things are coded. Before the introduction of
ObjectSynchronizer::quick_enter(), the runtime helper would always
initialize the displaced header as appropriate. When
ObjectSynchronizer::quick_enter() was introduced it changed the
"interface contract" of the monitor enter runtime helper because there
is one special case where it no longer always initializes the
displaced header as appropriate.

I believe that the better design and "interface contract" is to have
the runtime helper always set the displaced header as appropriate
(apply change to ObjectSynchronizer::quick_enter and no other changes)
for the following reasons.
- Less coupling between JIT code and runtime helper, this coupling
helped lead to a number of time consuming bugs including 8153107,
8077392, and this one.
- Every place that slow case runtime helper is called, special care is
required to initialize displaced header, rather then in just one place
in ObjectSynchronizer::quick_enter.
- This coupling is also exposed through the
JVMCIRuntime::monitorenter(JavaThread, oopDesc, BasicLock) interface
and without updates to ObjectSynchronizer::quick_enter(), anyone (like
Graal, etc) calling this interface needs to make sure
BasicLock->_displaced_header is initialized to a non-zero value. My
guess is that without removing this requirement there may be future
deadlock issues. Also current users use JVMCIRuntime::monitorenter()
should be reviewed to ensure that they are initializing
BasicLock->_displaced_header.
- JIT inline code and JVMCIRuntime::monitorenter users can possibly be
smaller and faster, if the JIT inline code determines that the runtime
helper is needed it can simply call this without first having to
initialize the displaced header. Also note that JIT code may not have
the information to know exactly what to set displaced herder to, so I
will set it to non-zero and the runtime helper may overwrite this
value with something different based on the additional logic in the
slow path.
- Supports fixing -XX:-UseFastLocking develop flag without additional changes

But given that all code except ARM32 C1, assumes an "interface
contract" that has special case for when displaced header needs to be
initialized I am not sure that there will be much support for making
changes that impact all other architectures in the context of the
ARM32 bug fix (for other architectures there could be a redundant
setting displaced header to non-zero in
ObjectSynchronizer::quick_enter()).

Anyway, just my thoughts... I am fine with either location
(C1_MacroAssembler::lock_object/SharedRuntime::generate_native_wrapper
or ObjectSynchronizer::quick_enter) to fix this ARM32 bug.

> What I do not like in your fix is
> - an arbitrary non-zero value is put into disp_hdr address for 'ne' case.

I somewhat agree that in general the aesthetics of using an arbitrary
non-zero value isn't ideal. But in this case I believe setting to a
specific non-zero value would require an additional instruction and I
don't think this is worth it. Note that this JIT code is inlined to
every compiled synchronized method and block, so that one extra
instruction gets multiplied by a large number and increases memory
usage, especially important for ARM32 with devices generally having
limited memory.

The code change for C1_MacroAssembler::lock_object is taken from what
is done for ARM32 C2 code in C2_MacroAssembler::fast_lock(),
that is using an arbitrary non-zero value (see
https://github.com/openjdk/jdk/blob/b7b6acd9b1cafb791827e151712836c4e7140db5/src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp#L122).
I would suggest that all places should be consistent. Also when other
architectures call the runtime helper, the displaced header is
initialize with "unlocked object header" value due to failed attempt
to do a stack lock and this is somewhat arbitrary (and somewhat
misleading) (see
https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74).

Note that in this context the displaced header is acting like a
boolean, false = 0 and any other value is true.

So to keep the code small and to be consistent with ARM32 C2, I would
suggest just using non-zero value. Maybe a better comment in the code
would be helpful, as follows.

diff --git a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
index 9d5c82dceb9..44ddc3a9da9 100644
--- a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
+++ b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
@@ -235,7 +235,11 @@ int C1_MacroAssembler::lock_object(Register hdr,
Register obj,
   sub(tmp2, hdr, SP, eq);
   movs(tmp2, AsmOperand(tmp2, lsr, exact_log2(os::vm_page_size())), eq);
   // If 'eq' then OK for recursive fast locking: store 0 into a lock record.
-  str(tmp2, Address(disp_hdr, mark_offset), eq);
+  // If 'ne' then initialize displaced header with this non-zero value
+  // to make sure monitor exit is not treated as non-inflated recursive unlock,
+  // the runtime helper used in slow case doesn't always do this for us
+  // (see discussion in JDK-8267042)
+  str(tmp2, Address(disp_hdr, mark_offset));
   b(fast_lock_done, eq);
   // else need slow case
   b(slow_case);


> - there is a similar code pattern in
> SharedRuntime::generate_native_wrapper - should not it be fixed too?

Good catch, yes this needs to be fixed as well. I would suggest same
change as for C1_MacroAssembler::lock_object, as follows.

diff --git a/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
b/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
index 341cf63c4c9..7de4306aedb 100644
--- a/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
+++ b/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
@@ -1184,7 +1184,11 @@ nmethod*
SharedRuntime::generate_native_wrapper(MacroAssembler* masm,
     __ sub(Rtemp, mark, SP, eq);
     __ movs(Rtemp, AsmOperand(Rtemp, lsr, exact_log2(os::vm_page_size())), eq);
     // If still 'eq' then recursive locking OK: set displaced header to 0
-    __ str(Rtemp, Address(disp_hdr,
BasicLock::displaced_header_offset_in_bytes()), eq);
+    // If 'ne' then initialize displaced header with this non-zero value
+    // to make sure monitor exit is not treated as non-inflated
recursive unlock,
+    // the runtime helper used in slow case doesn't always do this for us
+    // (see discussion in JDK-8267042)
+    __ str(Rtemp, Address(disp_hdr,
BasicLock::displaced_header_offset_in_bytes()));
     __ b(lock_done, eq);
     __ b(slow_lock);

> - the second comment in hdr bits manipulation code is wrong: "// -2-
> test (hdr - SP) if the low two bits are 0"

What are you suggesting is wrong? If I read this as a comment about
the two instructions that follow (sub and movs) then seems to make
sense to me, but I might be missing something. Also I would think this
is not really related to this issue and addressed in a separate place
issue?

Thanks again,
Chris

>
> regards,
> Boris
>

From x4e_x4e at protonmail.com  Thu May 20 17:18:09 2021
From: x4e_x4e at protonmail.com (x4e_x4e)
Date: Thu, 20 May 2021 17:18:09 +0000
Subject: Suppressed IllegalAccessException in MethodHandle.setVarargs
Message-ID: <mb78-nTTCd951gQ4ZiPP1rIwH9eMoapeUcQ6a42OAOtqE1MQnWL5sWz6b3JiBhyxTKZP-KLelVzodf-5DGmJIzCRVoopvsFO4RKuXuN0gPg=@protonmail.com>

Hello,

If a MethodHandles.Lookup is used to locate a MethodHandle for a varargs method who's final parameter is not an array an IllegalArgumentException will be thrown:

> java.lang.IllegalArgumentException: not an array type: int
>???? at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:138)
>???? at java.base/java.lang.invoke.MethodHandle.spreadArrayChecks(MethodHandle.java:1066)
>???? at java.base/java.lang.invoke.MethodHandle.asCollectorChecks(MethodHandle.java:1259)
>???? at java.base/java.lang.invoke.MethodHandle.asVarargsCollector(MethodHandle.java:1427)
>???? at java.base/java.lang.invoke.MethodHandle.withVarargs(MethodHandle.java:1111)
>???? at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1634)
>?? ? at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755)
>???? at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691)
>???? at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399)

This makes sense, however it seems that the exception is swallowed and instead a generic IllegalAccessException is thrown:

> Caused by: java.lang.IllegalAccessException: cannot make variable arity: package.Class.method(Object[],int)Object/invokeStatic
>     at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:957)
>     at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1636)
>     at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755)
>     at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691)
>     at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399)

It would probably be helpful to make the IllegalAccessException caused by the IllegalArgumentException, or at the very least add it as a suppressed exception.
Otherwise the only way to find the helpful exception here is through runtime debugging.

Relevant code: https://github.com/openjdk/jdk/blob/7b98400c81900a8c779394d549b5fb61f1dd8638/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1635

Thanks,
x4e

From alanb at openjdk.java.net  Thu May 20 17:45:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 17:45:45 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <L7XeCk-YX6SmwyXJDDOYrowlXUCgq6DABx4BNz4I8yI=.2787454d-b6ae-4426-831b-75f64b9ed7af@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
 <L7XeCk-YX6SmwyXJDDOYrowlXUCgq6DABx4BNz4I8yI=.2787454d-b6ae-4426-831b-75f64b9ed7af@github.com>
Message-ID: <8LA0NkO48Sxqf8ITGs8HWtyQhcr5oK5sbMBcYYOZCe0=.5c378205-caed-467e-9dc3-999b5dd54b05@github.com>

On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466:
>> 
>>> 464:     }
>>> 465: 
>>> 466:     private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();
>> 
>> It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil.
>
> I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code.
> 
> Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome.
> 
> Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that?

Can you create a follow-on issue to re-visit the changes to IOUtil? The changes in this area that are in this PR will need to re-worked so that it more cleanly separate the synchronous and asynchronous usages.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From sspitsyn at openjdk.java.net  Thu May 20 18:24:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 20 May 2021 18:24:29 GMT
Subject: RFR: 8266967: debug.cpp utility find() should print Java Object
 fields. [v2]
In-Reply-To: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com>
References: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
 <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com>
Message-ID: <QM9ylugFbx2jKrDl527y687mxOWKASaupX1YzYV8cjg=.076f5226-4f41-4a42-9bb8-8fec1e494845@github.com>

On Thu, 13 May 2021 13:24:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This change enables debug.cpp's find() utility to print Java Objects with their fields.
>> 
>> find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on.
>> Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work.
>> 
>> 
>> Checking other uses of os::print_location this might affect:
>> 
>> macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64
>> which use os::print_location to print register contents and print words at top of stack.
>> These will be more verbose, as it already is in non-PRODUCT builds.
>> 
>> vmError uses os::print_location when showing the stack, i.e. this output:
>> 
>> Stack slot to memory mapping:
>> stack at sp + 0 slots: 0x0000000000000002 is an unknown value
>> ..etc...
>> 
>> ...will be more verbose when Java object references are found (for the 8 stack slots it tries to show).
>> 
>> 
>> Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes.
>> 
>> 
>> Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only:
>> 
>> "Executing find"
>> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
>> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
>> 
>> ...then with the change the full info:
>> 
>> "Executing find"
>> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
>> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
>>  - ---- fields (total size 13 words):
>>  - private 'defaultAssertionStatus' 'Z' @12  false
>>  - private final 'parent' 'Ljava/lang/ClassLoader;' @24  a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a
>> 40} (ff0a0a40)
>>  - private final 'name' 'Ljava/lang/String;' @28  "app"{0x00000000ff0d0060} (ff0d0060)
>>  - private final 'unnamedModule' 'Ljava/lang/Module;' @32  a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448)
>> ...etc...
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ifdef correction

Hi Kevin,
The fix looks okay to me.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4011

From xliu at openjdk.java.net  Thu May 20 18:29:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 18:29:41 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <45oe9uTZ_ag9xbifP-Z_szaUELpspFNX7mA6EUL8zKc=.ebbd7c30-1e5b-485d-aa36-59d00b8961db@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

Thanks. I will do behavioral test for this patch on Windows before integrating it. 
stay tuned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/4073

From mandy.chung at oracle.com  Thu May 20 18:43:26 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 20 May 2021 11:43:26 -0700
Subject: Suppressed IllegalAccessException in MethodHandle.setVarargs
In-Reply-To: <mb78-nTTCd951gQ4ZiPP1rIwH9eMoapeUcQ6a42OAOtqE1MQnWL5sWz6b3JiBhyxTKZP-KLelVzodf-5DGmJIzCRVoopvsFO4RKuXuN0gPg=@protonmail.com>
References: <mb78-nTTCd951gQ4ZiPP1rIwH9eMoapeUcQ6a42OAOtqE1MQnWL5sWz6b3JiBhyxTKZP-KLelVzodf-5DGmJIzCRVoopvsFO4RKuXuN0gPg=@protonmail.com>
Message-ID: <4e89c1b0-2b43-9f27-4939-7af89974501d@oracle.com>

This seems a good improvement.? I created 
https://bugs.openjdk.java.net/browse/JDK-8267509 for this issue.

How did you run into this illegal varargs method?? Is that class file 
generated at runtime?

Mandy

On 5/20/21 10:18 AM, x4e_x4e wrote:
> Hello,
>
> If a MethodHandles.Lookup is used to locate a MethodHandle for a varargs method who's final parameter is not an array an IllegalArgumentException will be thrown:
>
>> java.lang.IllegalArgumentException: not an array type: int
>>  ???? at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:138)
>>  ???? at java.base/java.lang.invoke.MethodHandle.spreadArrayChecks(MethodHandle.java:1066)
>>  ???? at java.base/java.lang.invoke.MethodHandle.asCollectorChecks(MethodHandle.java:1259)
>>  ???? at java.base/java.lang.invoke.MethodHandle.asVarargsCollector(MethodHandle.java:1427)
>>  ???? at java.base/java.lang.invoke.MethodHandle.withVarargs(MethodHandle.java:1111)
>>  ???? at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1634)
>>  ?? ? at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755)
>>  ???? at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691)
>>  ???? at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399)
> This makes sense, however it seems that the exception is swallowed and instead a generic IllegalAccessException is thrown:
>
>> Caused by: java.lang.IllegalAccessException: cannot make variable arity: package.Class.method(Object[],int)Object/invokeStatic
>>      at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:957)
>>      at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1636)
>>      at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755)
>>      at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691)
>>      at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399)
> It would probably be helpful to make the IllegalAccessException caused by the IllegalArgumentException, or at the very least add it as a suppressed exception.
> Otherwise the only way to find the helpful exception here is through runtime debugging.
>
> Relevant code: https://github.com/openjdk/jdk/blob/7b98400c81900a8c779394d549b5fb61f1dd8638/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1635
>
> Thanks,
> x4e


From gziemski at openjdk.java.net  Thu May 20 21:38:33 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 20 May 2021 21:38:33 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v2]
In-Reply-To: <7gEM1aNO-ZZEYc4p6en6PgcDoEjXe8lq-XYGSsTFl6c=.6df45640-716f-47f3-a251-2b3e775a62a4@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
 <sL17KDYLFhcxAM0lJGhxwuLbwbbM7Ke-p7Lkq5FNA2Y=.16565590-cd88-4be8-9883-dbcc5e27b2de@github.com>
 <7gEM1aNO-ZZEYc4p6en6PgcDoEjXe8lq-XYGSsTFl6c=.6df45640-716f-47f3-a251-2b3e775a62a4@github.com>
Message-ID: <2X6wKmdLVTsF2l-hCMK9ADl3cVNZEnsvKL9mShhYEn0=.04e22225-4fe1-4c48-bd92-a1106d26ab10@github.com>

On Wed, 19 May 2021 16:01:11 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp line 42:
>> 
>>> 40: inline address pauth_strip_pointer(address ptr) {
>>> 41: #ifdef __APPLE__
>>> 42:   ptrauth_strip(ptr, ptrauth_key_asib);
>> 
>> Wouldn't it be safer to use the alias `ptrauth_key_process_dependent_code` instead of the underlaying primitive enum `ptrauth_key_asib`?
>> 
>> `  ptrauth_strip(ptr, ptrauth_key_process_dependent_code);`
>> 
>> Can you please elaborate on why this particular key was used, for example why not `ptrauth_key_process_independent_code`? There are so many other...
>
> For the values being stripped in this patch, they will always be return addresses saved on the stack. My first choice here was ptrauth_key_return_address, but I wanted it to be a little more generic and:
> ptrauth_key_return_address = ptrauth_key_process_dependent_code = ptrauth_key_asib [1]
> 
> For a strip function, the key shouldn't matter as xpaci/xaplri instructions work for both IA and IB keys. However when I've dumped my test binaries on mac, it looked like the compiler used generic bitmasking instead of the xpac instructions. So it's possible the relevant key does matter here. Using the IB key ensures ptrauth_strip() always does the stripping (according to ptrauth.h comments), which is probably the safest option for now. I suspect full mac arm64e support would eventually require having multiple strip functions (pauth_strip_retaddr(), pauth_strip_functptr(), etc)
> 
> [1] https://opensource.apple.com/source/xnu/xnu-4903.241.1/EXTERNAL_HEADERS/ptrauth.h.auto.html

I don't 100% understand this piece of code on macOS (I stripped non macOS code from it for clarity):


inline address pauth_strip_pointer(address ptr) {
   ptrauth_strip(ptr, ptrauth_key_asib);
   return ptr;
 }


shouldn't it be something more like:


inline address pauth_strip_pointer(address ptr) {
   return ptrauth_strip(ptr, ptrauth_key_asib);
 }


The original code compiles with **"Expression result unused"** for me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From ddong at openjdk.java.net  Thu May 20 22:22:50 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 20 May 2021 22:22:50 GMT
Subject: Integrated: 8266642: improve ResolvedMethodTable hash function
In-Reply-To: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
Message-ID: <4f-aYFXRn2WAlgV1B1Y_UBf4HIs7qaGyqBzdeDyjwbM=.1a67a05b-f5c8-4a44-85bf-8d426547fb44@github.com>

On Thu, 6 May 2021 14:25:40 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.

This pull request has now been integrated.

Changeset: 83b36072
Author:    Denghui Dong <ddong at openjdk.org>
Committer: Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83b360729060abaefb00a0b3f6165926db956bf8
Stats:     21 lines in 3 files changed: 19 ins; 0 del; 2 mod

8266642: improve ResolvedMethodTable hash function

Reviewed-by: vlivanov, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From vlivanov at openjdk.java.net  Thu May 20 22:22:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 20 May 2021 22:22:49 GMT
Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9]
In-Reply-To: <gWqimOho65l_cm0ub7jE2Op-ayWhXpRIsr7AoV3cHBM=.131f808f-fd6e-4d48-bfd6-b7b39047bf0a@github.com>
References: <QW9BGYsZ6RIF6Z05zRh9XiRF1ePueOyDON28wMABWWY=.ec70c5fe-ae38-49b7-91bd-528cb6eb910d@github.com>
 <gWqimOho65l_cm0ub7jE2Op-ayWhXpRIsr7AoV3cHBM=.131f808f-fd6e-4d48-bfd6-b7b39047bf0a@github.com>
Message-ID: <PJyKzQ1BzIiDbRyMkRGU76Aj-xZe1_k3Ju0VXpQVGWM=.9fb04837-9dac-40ed-b84b-f2299c711a3e@github.com>

On Tue, 18 May 2021 11:39:04 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remote LogMinObjAlignmentInBytes

Tier1-tier2 results are good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901

From paul.sandoz at oracle.com  Thu May 20 22:30:52 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 20 May 2021 22:30:52 +0000
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support
In-Reply-To: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
Message-ID: <B2D38C5E-8F40-484C-98DF-45F985B0E85C@oracle.com>

Hi Ningsheng,

Thank you for doing this work and preparing a review.

We might have our wires crossed a little with regards to JEPs, or we just need to clarify the intent.

I think this important work needs to be part of a Vector API JEP, it being a relevant new feature (in this case with a large contribution of code). That approach has been applied to the SVML support on x86 which is currently part of JEP 414, in addition to the API enhancements. I don?t think we can skip the JEP process for such a feature, and especially so since this is an incubating feature.

The reason I did not included SVE support in JEP 414, as we discussed, was because it may be too late to get the code properly reviewed in time by 17 RDP 1 (feature freeze on 2021/06/10).
(Note that JEP 414 currently explicitly calls out SVE support as future work.)

It's not that the JEP process takes time, it's that code reviews can take time, especially closer to RDP 1 as reviewers are often very busy.

If you and the reviewers think the code can be reviewed by 17 RDP 1 then we can update JEP 414 and include it. But, I strongly recommend we should include it in a further JEP we can plan and propose to target for 18 (I can prepare a new draft JEP after JEP 414 integrates).

However, to be clear, that does not negate starting the code review process now as you have done, in fact that?s a good thing :-) being prepared for a proposed release early in that release cycle reduces risk and increases chances of integration.

Paul.

> On May 20, 2021, at 12:48 AM, Ningsheng Jian <njian at openjdk.java.net> wrote:
> 
> This is the integration of current SVE work done in panama-vector/vectorIntrinscs, which includes:
> 
> 1. Code generation for Vector API c2 IR nodes with SVE.
> 2. Non-max vector size support with SVE, e.g. using *128Vector (and *64Vector) APIs on 256-bit SVE environment could also generate optimized SVE instructions with predicate feature.
> 3. Some more SVE assemblers (and tests) used by the codegen part.
> 
> Test: tier1-3 with vector api test cases passed on 512-bit SVE hardware with MaxVectorSize=16/32/64.
> 
> Note: our original plan was making this work part of JEP 414 Vector API (Second Incubator) [1], but we realized that it's now close to 17 release cycle and the JEP process may take time. Adding more features could delay the whole review process for the JEP. So we separate this work out as a standalone patch.
> 
> [1] http://openjdk.java.net/jeps/414
> 
> -------------
> 
> Commit messages:
> - 8267356: AArch64: Vector API SVE codegen support
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4122/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4122&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8267356
>  Stats: 5486 lines in 10 files changed: 4556 ins; 144 del; 786 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/4122.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4122/head:pull/4122
> 
> PR: https://git.openjdk.java.net/jdk/pull/4122


From david.holmes at oracle.com  Thu May 20 22:58:28 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 May 2021 08:58:28 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <NCbHsmGqySMeNLQW58Od2qGXrgTQqBXvtvQhZzX5DA8=.5931a3a2-3df4-46fe-951b-20a9505eb9e0@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <NCbHsmGqySMeNLQW58Od2qGXrgTQqBXvtvQhZzX5DA8=.5931a3a2-3df4-46fe-951b-20a9505eb9e0@github.com>
Message-ID: <b4746b68-a72c-644c-09a4-8efc16955c51@oracle.com>

On 21/05/2021 12:03 am, Thomas Stuefe wrote:
> On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>> underlying files periodically.
>>
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update according to reviewer's feedback.
> 
> Hi Xin,
> 
> Looks good to me too. Ship it.

I guess I'd better take look now that the dust has settled. :)

David

> ..Thomas
> 
> -------------
> 
> Marked as reviewed by stuefe (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From phh at openjdk.java.net  Thu May 20 23:02:42 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 20 May 2021 23:02:42 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <db6uuVoLvf9J20m8FQcck4EX3oI3ugZJTXa93tcpY04=.bc30db13-b4f0-48a5-b16a-a7edfc8613d6@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

A few comment typos, but otherwise looks fine.

src/hotspot/share/logging/logAsyncWriter.cpp line 121:

> 119:   // Use kind of copy-and-swap idiom here.
> 120:   // Empty 'logs' swaps the content with _buffer.
> 121:   // Along with logs destruction, all procceeded messages are deleted.

procceeded -> preceding

src/hotspot/share/logging/logAsyncWriter.cpp line 170:

> 168:       Atomic::release_store_fence(&AsyncLogWriter::_instance, self);
> 169:       // All readers of _instance after the fence see non-NULL.
> 170:       // We make use LogOutputList's RCU counters to ensure all synchronous logsites have completed.

Delete 'make'.

src/hotspot/share/logging/logAsyncWriter.cpp line 171:

> 169:       // All readers of _instance after the fence see non-NULL.
> 170:       // We make use LogOutputList's RCU counters to ensure all synchronous logsites have completed.
> 171:       // After that, we start AsyncLog Thread and it exclusively takee over all logging I/O.

takee -> takes

src/hotspot/share/logging/logAsyncWriter.hpp line 26:

> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP
> 26: #include "logging/log.hpp"

Use SHARE_LOGGING_LOGASYNCHWRITER_HPP to conform with existing naming standard.

src/hotspot/share/logging/logAsyncWriter.hpp line 128:

> 126:   AsyncLogBuffer _buffer;
> 127: 
> 128:   // The memory use of each AsyncLogMessage(payload) consist of itself and a variable-length c-str message.

consist -> consists

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 20 23:41:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 20 May 2021 23:41:37 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <db6uuVoLvf9J20m8FQcck4EX3oI3ugZJTXa93tcpY04=.bc30db13-b4f0-48a5-b16a-a7edfc8613d6@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <db6uuVoLvf9J20m8FQcck4EX3oI3ugZJTXa93tcpY04=.bc30db13-b4f0-48a5-b16a-a7edfc8613d6@github.com>
Message-ID: <wSbkRZiGcbG2ob154ep9bMnEZV0RnEYFYKlM3Eyvmto=.6e438998-cf96-41b6-b1c6-fc8e22b49382@github.com>

On Thu, 20 May 2021 22:50:26 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 121:
> 
>> 119:   // Use kind of copy-and-swap idiom here.
>> 120:   // Empty 'logs' swaps the content with _buffer.
>> 121:   // Along with logs destruction, all procceeded messages are deleted.
> 
> procceeded -> preceding

typo:  proccessed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From ningsheng.jian at arm.com  Fri May 21 02:16:29 2021
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Fri, 21 May 2021 10:16:29 +0800
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support
In-Reply-To: <B2D38C5E-8F40-484C-98DF-45F985B0E85C@oracle.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <B2D38C5E-8F40-484C-98DF-45F985B0E85C@oracle.com>
Message-ID: <7710bb66-0712-66cb-7ffc-1559975d6394@arm.com>

Hi Paul,

Thanks for the clarification about JEP process.

On 5/21/21 6:30 AM, Paul Sandoz wrote:
> Hi Ningsheng,
> 
> Thank you for doing this work and preparing a review.
> 
> We might have our wires crossed a little with regards to JEPs, or we just need to clarify the intent.
> 
> I think this important work needs to be part of a Vector API JEP, it being a relevant new feature (in this case with a large contribution of code). That approach has been applied to the SVML support on x86 which is currently part of JEP 414, in addition to the API enhancements. I don?t think we can skip the JEP process for such a feature, and especially so since this is an incubating feature.
> 
> The reason I did not included SVE support in JEP 414, as we discussed, was because it may be too late to get the code properly reviewed in time by 17 RDP 1 (feature freeze on 2021/06/10).
> (Note that JEP 414 currently explicitly calls out SVE support as future work.)
> 
> It's not that the JEP process takes time, it's that code reviews can take time, especially closer to RDP 1 as reviewers are often very busy.
> 
> If you and the reviewers think the code can be reviewed by 17 RDP 1 then we can update JEP 414 and include it. But, I strongly recommend we should include it in a further JEP we can plan and propose to target for 18 (I can prepare a new draft JEP after JEP 414 integrates).
> 

Agree that this SVE support feature needs to be included in Vector API 
JEP. I am not familiar with the JEP process, but it seems to me that 
updating JEP 414 at the last minute is risky. So, I am happy to defer 
the integration until 18, with another Vector API JEP.

> However, to be clear, that does not negate starting the code review process now as you have done, in fact that?s a good thing :-) being prepared for a proposed release early in that release cycle reduces risk and increases chances of integration.
> 

Yes, review comments for this patch are welcome. :-) I have set the "Fix 
Version" to 18 in JBS.

Thanks,
Ningsheng



From manc at openjdk.java.net  Fri May 21 02:18:32 2021
From: manc at openjdk.java.net (Man Cao)
Date: Fri, 21 May 2021 02:18:32 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <ValyQssTnr2SMWk40TA5y7D_jNZVtNs7zIvD6LasJ5I=.db2abe37-55b2-4f95-87aa-7c1372e2b3ea@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Re David's comment:

> Still not clear why this is necessary. The target thread is just as
> blocked or in native during a GC pause safepoint, as it is during a
> handshake. So if the GC can process them in one case surely it can do
> both. ??

There is no association between a dirty card and Java thread(s). Even if we have such association, i.e. we track which thread produced the dirty card, it is still insufficient to coordinate with only the dirtying thread. This is because other threads could have observed the card being dirty and performed a store to Java heap, without doing any fence or synchronization. Later, the refinement thread (the requesting thread) needs to load from the Java heap range mapped to the dirty card's address for the refinement work.
Thus, it is only safe to load from the Java heap range under one of the two conditions:
- The requesting thread has finished epoch synchronization with **all** Java threads. 
- It is at a safepoint where **all** Java threads have been synchronized and stopped.

Either condition guarantees that previous stores to the Java heap range mapped to the card's address are visible to the loading thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From ysuenaga at openjdk.java.net  Fri May 21 02:24:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 21 May 2021 02:24:40 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <0gyTt86S8OkIhmA2ZjjrUs8hKUIN4hWTnx4rLCL-mSE=.01b40140-8838-46b2-9207-b9dff8d57180@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

Looks good! Thank you for working for it!

-------------

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From david.holmes at oracle.com  Fri May 21 02:55:44 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 May 2021 12:55:44 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <ValyQssTnr2SMWk40TA5y7D_jNZVtNs7zIvD6LasJ5I=.db2abe37-55b2-4f95-87aa-7c1372e2b3ea@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
 <ValyQssTnr2SMWk40TA5y7D_jNZVtNs7zIvD6LasJ5I=.db2abe37-55b2-4f95-87aa-7c1372e2b3ea@github.com>
Message-ID: <d95ce119-d532-bf8a-bc99-267481abd98c@oracle.com>

On 21/05/2021 12:18 pm, Man Cao wrote:
> On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:
> 
>>> Hi all,
>>>
>>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>>>
>>> -Man
>>
>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Added missing deallocation and renamed "remote" to "non-self".
> 
> Re David's comment:
> 
>> Still not clear why this is necessary. The target thread is just as
>> blocked or in native during a GC pause safepoint, as it is during a
>> handshake. So if the GC can process them in one case surely it can do
>> both. ??
> 
> There is no association between a dirty card and Java thread(s). Even if we have such association, i.e. we track which thread produced the dirty card, it is still insufficient to coordinate with only the dirtying thread. This is because other threads could have observed the card being dirty and performed a store to Java heap, without doing any fence or synchronization. Later, the refinement thread (the requesting thread) needs to load from the Java heap range mapped to the dirty card's address for the refinement work.
> Thus, it is only safe to load from the Java heap range under one of the two conditions:
> - The requesting thread has finished epoch synchronization with **all** Java threads.
> - It is at a safepoint where **all** Java threads have been synchronized and stopped.
> 
> Either condition guarantees that previous stores to the Java heap range mapped to the card's address are visible to the loading thread.

If it is an all or none proposition then I don't see what skipping 
blocked threads has to do with this ??? Sorry I think I'm losing track 
of issues.

David


> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From manc at openjdk.java.net  Fri May 21 02:57:28 2021
From: manc at openjdk.java.net (Man Cao)
Date: Fri, 21 May 2021 02:57:28 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <OBgY4b7M70yMtYb98IQc90HiR3h2wE-cduIClMtChls=.a69f4798-d711-448d-bc0a-6baeac3dfbf7@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Re Robin's comment:

> This line is just confusing, the requesting thread only enters a safepoint if it's a JavaThread.
> ...
> Not sure if this epoch sync is run by a thread part of SuspendibleThreadSet or not, but:

Yes it is confusing. Let me clarify the problem.

The epoch sync is requested by either a G1 refinement thread, which is a part of SuspendibleThreadSet; or a Java thread from its post-write barrier's slow path, which is a JRT_LEAF function that forbids any operation that can safepoint. G1 by design supports concurrent refinement from a Java thread's post-write barrier, if there's too many cards to refine, see G1DirtyCardQueueSet::handle_completed_buffer().

I could get the epoch sync working using synchronous handshake when requesting thread == G1 refinement thread, by leaving SuspendibleThreadSet and redirtying some pending cards before calling Handshake::execute(). However, it does not work for the requesting thread == Java thread case, due to the JRT_LEAF constraint. This is the reason for proposing to use Handshake::enqueue() and support executing them from non-self threads.

> If it is; it is just prolonging the time to safepoint, which is a free epoch, thus finishing the epoch just wastes CPU.

Good point. I'll make sure any waiting in the epoch sync protocol also checks for pending safepoint and yields.

Anyway, I think the arm-the-poll-only approach is superior and it does not need to issue any handshake. I will look into that instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From xliu at openjdk.java.net  Fri May 21 02:58:37 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 02:58:37 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v14]
In-Reply-To: <bfBviEJ6-OxbK1PkD02szIY36a1qAnFCwKzzwZLUO6A=.874d859d-44cf-44e4-abf7-b9abbfd72ebd@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <5Uzc5FJelImFTNBMVXBozW_xMbJpPJbLTtgqXKF0ZBU=.54c3eddd-bca0-450c-8b68-2d545b314e00@github.com>
 <g2BsutcKof8nMhi-KuP2l6GBuk-4xYFmL7MHEI2DKRY=.9be05a71-62b4-431e-a9f7-4a237c04c735@github.com>
 <2f2-tIuGEZUa8Z30qY_JhTDokXXwqdaxja6j_tA5HxY=.a214ff28-ba58-4a3f-8ee6-7f4a9c037a36@github.com>
 <bfBviEJ6-OxbK1PkD02szIY36a1qAnFCwKzzwZLUO6A=.874d859d-44cf-44e4-abf7-b9abbfd72ebd@github.com>
Message-ID: <QFP3ZnlE4ZTSW-hmPhlfHN0AwLlsog4MrjB9BdEUu8o=.47ba0dcd-c79c-48d5-b096-87ac0a92f4ce@github.com>

On Fri, 14 May 2021 04:19:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> enqueue_impl() is private. it's not accessible from outside. 
>> only public member functions can be seen by clients.
>
>> enqueue_impl() is private. it's not accessible from outside.
>> only public member functions can be seen by clients.
> 
> What I meant is, can logging - hence enqueing - be done from the async thread itself? Can it happen that the logger thread itself logs, would that be a problem, and if yes, should we guard against it?

Actually, it could happen. This line is the very first 'log' from AsyncLog Thread. 

  void pre_run() override {
    NonJavaThread::pre_run();
    log_debug(logging, thread)("starting AsyncLog Thread tid = " INTX_FORMAT, os::current_thread_id());
  }

This logsite is handled exactly same as other logsites. grab the lock, enqueue the cloned message and return -1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From manc at openjdk.java.net  Fri May 21 03:34:37 2021
From: manc at openjdk.java.net (Man Cao)
Date: Fri, 21 May 2021 03:34:37 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <d95ce119-d532-bf8a-bc99-267481abd98c@oracle.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <d95ce119-d532-bf8a-bc99-267481abd98c@oracle.com>
Message-ID: <qn_7ORh3hb6WtR1XDpkXjcwZ1VaF5i89L2JRCclq9Yg=.68af45f9-e15f-4509-8946-98a4a43ed706@github.com>

On Fri, 21 May 2021 02:57:06 GMT, David Holmes <david.holmes at oracle.com> wrote:

> If it is an all or none proposition then I don't see what skipping
> blocked threads has to do with this ??? Sorry I think I'm losing track
> of issues.

There's a per-thread epoch counter that determines each thread's progress for an epoch sync request.
A blocked thread cannot update its epoch counter by itself, so the requesting thread needs to "skip" the blocked thread by first checking if the target thread is blocked, then doing either:
- treats the target thread's epoch counter as >= the requested counter value;
- updates the target thread's counter on behalf of the target thread.

Either approach ensures forward progress when encountering a blocked thread. Otherwise, any blocked thread would prevent the epoch sync from finishing, leading to deferred cards.

Perhaps the description of https://bugs.openjdk.java.net/browse/JDK-8236485 can help understand it?

Anyway, this is beyond this PR. What do we want to do with this PR? The epoch sync protocol will not depend on it if it uses the arm-the-poll-only approach.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From david.holmes at oracle.com  Fri May 21 03:50:16 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 May 2021 13:50:16 +1000
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread
In-Reply-To: <qn_7ORh3hb6WtR1XDpkXjcwZ1VaF5i89L2JRCclq9Yg=.68af45f9-e15f-4509-8946-98a4a43ed706@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <d95ce119-d532-bf8a-bc99-267481abd98c@oracle.com>
 <qn_7ORh3hb6WtR1XDpkXjcwZ1VaF5i89L2JRCclq9Yg=.68af45f9-e15f-4509-8946-98a4a43ed706@github.com>
Message-ID: <4c747ed4-8c5c-7e80-8b0c-618346bfc568@oracle.com>

On 21/05/2021 1:34 pm, Man Cao wrote:
> On Fri, 21 May 2021 02:57:06 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> If it is an all or none proposition then I don't see what skipping
>> blocked threads has to do with this ??? Sorry I think I'm losing track
>> of issues.
> 
> There's a per-thread epoch counter that determines each thread's progress for an epoch sync request.
> A blocked thread cannot update its epoch counter by itself, so the requesting thread needs to "skip" the blocked thread by first checking if the target thread is blocked, then doing either:
> - treats the target thread's epoch counter as >= the requested counter value;
> - updates the target thread's counter on behalf of the target thread.
> 
> Either approach ensures forward progress when encountering a blocked thread. Otherwise, any blocked thread would prevent the epoch sync from finishing, leading to deferred cards.
> 
> Perhaps the description of https://bugs.openjdk.java.net/browse/JDK-8236485 can help understand it?
> 
> Anyway, this is beyond this PR. What do we want to do with this PR? The epoch sync protocol will not depend on it if it uses the arm-the-poll-only approach.

Without a solid use-case to drive the design decisions it isn't clear to 
me exactly what the current PR should look like. I think until we have 
something that needs and will use this enhanced mechanism then we should 
leave it as-is.

Cheers,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
> 

From dholmes at openjdk.java.net  Fri May 21 06:24:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 21 May 2021 06:24:00 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

Overall I think this has shaped up rather well - thank you!

Hard for me to fully grok everything by reading the code though so I've requested a summary of operation comment in the header file.

Otherwise minor, mostly grammatical, comments.

Thanks,
David

src/hotspot/share/logging/logAsyncWriter.cpp line 75:

> 73: }
> 74: 
> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.

typo: messages -> message

src/hotspot/share/logging/logAsyncWriter.cpp line 76:

> 74: 
> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.
> 76: // the mutex here gurantees its integrity.

typo: gurantees -> guarantees

src/hotspot/share/logging/logAsyncWriter.cpp line 118:

> 116: };
> 117: 
> 118: void AsyncLogWriter::perform_IO() {

Seems to be all O and no I :)

src/hotspot/share/logging/logAsyncWriter.cpp line 164:

> 162:   if (!LogConfiguration::is_async_mode()) return;
> 163: 
> 164:   if (_instance == nullptr) {

This method should only be called once so _instance must be NULL. An assert rather than an if would suffice.

src/hotspot/share/logging/logAsyncWriter.cpp line 175:

> 173:         ts->wait_until_no_readers();
> 174:       }
> 175:       self->_state = ThreadState::Running;

This seems like something the thread itself should do at the start of run()

src/hotspot/share/logging/logAsyncWriter.cpp line 177:

> 175:       self->_state = ThreadState::Running;
> 176:       os::start_thread(self);
> 177:       log_debug(logging, thread)("AsyncLogging starts working.");

Suggest: "Async logging thread started"

src/hotspot/share/logging/logAsyncWriter.cpp line 179:

> 177:       log_debug(logging, thread)("AsyncLogging starts working.");
> 178:     } else {
> 179:       log_warning(logging, thread)("AsyncLogging failed to launch thread. fall back to synchronous logging.");

"Async logging failed to create thread. Falling back to synchronous logging."

Shouldn't this be done where the os::create_thread failed though?

src/hotspot/share/logging/logAsyncWriter.hpp line 25:

> 23:  */
> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP

Typos: WTRITER

src/hotspot/share/logging/logAsyncWriter.hpp line 34:

> 32: #include "utilities/hashtable.hpp"
> 33: #include "utilities/linkedlist.hpp"
> 34: 

Could you write a summary of operation comment explaining how async mode works e.g.  details on initialization and teardown, how the thread interacts with writers etc. Thanks.

src/hotspot/share/logging/logAsyncWriter.hpp line 113:

> 111: typedef KVHashtable<LogFileOutput*, uint32_t, mtLogging> AsyncLogMap;
> 112: 
> 113: class AsyncLogWriter: public NonJavaThread {

Any reason this is not a NamedThread? How will this appear in thread-dumps and crash reports?

Also I would have expected two classes to simplify the APIs: AsyncLogWriter and AsyncLogThread

src/hotspot/share/logging/logAsyncWriter.hpp line 115:

> 113: class AsyncLogWriter: public NonJavaThread {
> 114:   static AsyncLogWriter* _instance;
> 115:   static Semaphore _sem;

What is this semaphore for? A comment and/or a more meaningful name would be good.

src/hotspot/share/logging/logAsyncWriter.hpp line 125:

> 123: 
> 124:   volatile ThreadState _state;
> 125:   AsyncLogMap _stats; // statistics of dropping messages.

// statistics for dropped messages

src/hotspot/share/logging/logAsyncWriter.hpp line 147:

> 145: 
> 146:   // None of following functions are thread-safe.
> 147:   static AsyncLogWriter* instance();

instance() isn't thread-safe ??

src/hotspot/share/logging/logConfiguration.cpp line 555:

> 553:                                     " This will cause existing log files to be overwritten.");
> 554:   out->cr();
> 555:   out->print_cr("\nAsynchronous logging(off by default):");

space before "(off"

src/hotspot/share/runtime/globals.hpp line 1993:

> 1991:                                                                             \
> 1992:   product(size_t, AsyncLogBufferSize, 2*M,                                  \
> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \

space before (

src/hotspot/share/runtime/globals.hpp line 1995:

> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \
> 1994:           "Logging (-Xlog:async).")                                         \
> 1995:           range(100*K, 50*M)                                                \

What is the basis for this range?

src/hotspot/share/runtime/init.cpp line 127:

> 125:     return status;
> 126: 
> 127:   AsyncLogWriter::initialize();

So prior to this point logging has been synchronous and now we switch if async-mode?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From rehn at openjdk.java.net  Fri May 21 06:29:27 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 21 May 2021 06:29:27 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <OBgY4b7M70yMtYb98IQc90HiR3h2wE-cduIClMtChls=.a69f4798-d711-448d-bc0a-6baeac3dfbf7@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
 <OBgY4b7M70yMtYb98IQc90HiR3h2wE-cduIClMtChls=.a69f4798-d711-448d-bc0a-6baeac3dfbf7@github.com>
Message-ID: <lrT90pTfI_cfH5zaN4UFpODlKEDLLhs1BuupMQJrVbw=.bc1afc48-cf9f-41b1-9004-7d040b173968@github.com>

On Fri, 21 May 2021 02:55:00 GMT, Man Cao <manc at openjdk.org> wrote:

> Re Robin's comment:
> 
> > This line is just confusing, the requesting thread only enters a safepoint if it's a JavaThread.
> > ...
> > Not sure if this epoch sync is run by a thread part of SuspendibleThreadSet or not, but:
> 
> Yes it is confusing. Let me clarify the problem.
> 
> The epoch sync is requested by either a G1 refinement thread, which is a part of SuspendibleThreadSet; or a Java thread from its post-write barrier's slow path, which is a JRT_LEAF function that forbids any operation that can safepoint. G1 by design supports concurrent refinement from a Java thread's post-write barrier, if there's too many cards to refine, see G1DirtyCardQueueSet::handle_completed_buffer().
> 
> I could get the epoch sync working using synchronous handshake when requesting thread == G1 refinement thread, by leaving SuspendibleThreadSet and redirtying some pending cards before calling Handshake::execute(). However, it does not work for the requesting thread == Java thread case, due to the JRT_LEAF constraint. This is the reason for proposing to use Handshake::enqueue() and support executing them from non-self threads.
> 
> > If it is; it is just prolonging the time to safepoint, which is a free epoch, thus finishing the epoch just wastes CPU.
> 
> Good point. I'll make sure any waiting in the epoch sync protocol also checks for pending safepoint and yields.
> 
> Anyway, I think the arm-the-poll-only approach is superior and it does not need to issue any handshake. I will look into that instead.

If someone keeps suspending ad resuming a thread the thread might always have the poll armed and always have a handshake.
Just looking if queue is empty or not, or poll is armed or not can have pathological cases.
If you add an epoch counter into Thread::gc_data_offset you could update it by putting a line next cross-mod-fence:
`
void SafepointMechanism::process_if_requested_slow(JavaThread *thread) {
...
  OrderAccess::cross_modify_fence();
  Universe::heap()->barrier_complete(thread); // store global epoch to GCThreadLocalData
}
`
But as David said, you basically trying to handshake without a handshake :)
(should try to put the counter inside the handshake instead)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From xliu at openjdk.java.net  Fri May 21 07:03:39 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 07:03:39 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <S-cLt5hlLL0ymKcsbXLnYSwxWy4YvUHHCMEbhbEFGVw=.74581e03-2028-4d93-956c-3c51538e279e@github.com>

On Fri, 21 May 2021 06:10:43 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 according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 179:
> 
>> 177:       log_debug(logging, thread)("AsyncLogging starts working.");
>> 178:     } else {
>> 179:       log_warning(logging, thread)("AsyncLogging failed to launch thread. fall back to synchronous logging.");
> 
> "Async logging failed to create thread. Falling back to synchronous logging."
> 
> Shouldn't this be done where the os::create_thread failed though?

make sense.  I think I can move "Async logging failed to create thread. Falling back to synchronous logging."

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From manc at openjdk.java.net  Fri May 21 08:21:39 2021
From: manc at openjdk.java.net (Man Cao)
Date: Fri, 21 May 2021 08:21:39 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
Message-ID: <qOMjz8tDcb5XBlNzfw52ViTE1cz1yRVUz57knYTTo_s=.c87d3432-e143-4342-bc8a-4465233f52e3@github.com>

On Tue, 18 May 2021 19:08:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Thanks. Let me first do more experiment to validate first. I'll close this PR once confirming the other approach also works.

> If someone keeps suspending ad resuming a thread the thread might always have the poll armed and always have a handshake.
> Just looking if queue is empty or not, or poll is armed or not can have pathological cases.

If I understand the context correctly, the approach of updating the epoch counter in `process_if_requested_slow()` will prevent the pathological cases above? And yes, the current implementation already updates the epoch counter in `SafepointMechanism::update_poll_values()` similarly.

> If you add an epoch counter into Thread::gc_data_offset you could update it by putting a line next cross-mod-fence:
> `void SafepointMechanism::process_if_requested_slow(JavaThread *thread) { ... OrderAccess::cross_modify_fence(); Universe::heap()->barrier_complete(thread); // store global epoch to GCThreadLocalData }`

Thanks, adding a new virtual method in CollectedHeap is much cleaner than my current `if (UseG1GC) update_epoch_self();` approach.

> But as David said, you basically trying to handshake without a handshake :)
> (should try to put the counter inside the handshake instead)

One note is that a thread could also update its epoch counter in places that are irrelevant to polling or handshake. This could make epoch sync more responsive than handshakes. Currently I only added such update in `ThreadInVMfromJava`, since it is executed frequently. I'll evaluate whether this update still makes much difference in responsiveness.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From xliu at openjdk.java.net  Fri May 21 08:23:38 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 08:23:38 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <-W8PzPgase0LpMBOAaNaSerYBIh-K71EdubSFd4wtgM=.79b8f129-bfe7-4270-a2ff-d4ae084c85b2@github.com>

On Fri, 21 May 2021 06:16:30 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 according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 34:
> 
>> 32: #include "utilities/hashtable.hpp"
>> 33: #include "utilities/linkedlist.hpp"
>> 34: 
> 
> Could you write a summary of operation comment explaining how async mode works e.g.  details on initialization and teardown, how the thread interacts with writers etc. Thanks.

How about this?

`initialize()` is called once when JVM is initialized. It creates and initialize the singleton instance of AsyncLogWriter. Once async logging is established, there's no way to turn it off. 

`instance()` is MT-safe and returns the pointer of the singleton instance if and only if async mode is on and has well initialized.  Clients can use its return value to determine async logging is established or not. 

The basic operation of AsyncLogWriter is `enqueue`. Two overloading versions of it are provided to match `LogOutput::write`. To support async logging,  derived classes of LogOutput can invoke the corresponding AsyncLogWriter::enqueue in write() and return -1.  AsyncLogWriter is responsible of copying both decorations and cstr messages and managing their lifecycle. 

The static member function `flush`is designated to flush out all pending messages when JVM is terminating or aborting. In normal JVM termination, flush() is invoked in `LogConfiguration::finalize()`.  In abortion situation, `flush()` is invoked in `os::shutdown()`.  `flush` is MT-safe and can be invoked arbitrary times.  It is no-op if asynclogging is not established.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From rehn at openjdk.java.net  Fri May 21 08:26:32 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 21 May 2021 08:26:32 GMT
Subject: RFR: 8267079: Support async handshakes that can be executed by a
 remote thread [v2]
In-Reply-To: <qOMjz8tDcb5XBlNzfw52ViTE1cz1yRVUz57knYTTo_s=.c87d3432-e143-4342-bc8a-4465233f52e3@github.com>
References: <I9GCacLauL1bZHcJeKIA6ZYHYXSoB1oESBolQgG6aL4=.b00962c7-0b32-4d8e-ae72-341439a47167@github.com>
 <e3bSflfW4M5BngYUFTN9LiT1RS-Hkd99i_TysZIc2_k=.a8682eb9-666a-48d3-9fce-2ccd36b9b1e1@github.com>
 <qOMjz8tDcb5XBlNzfw52ViTE1cz1yRVUz57knYTTo_s=.c87d3432-e143-4342-bc8a-4465233f52e3@github.com>
Message-ID: <Ij3KyD6mLSiVBLC9TRwrww1lGhnkSQadWrZcVs7i0Io=.3684a0ef-02b3-4bcc-ac6a-a761454f7a67@github.com>

On Fri, 21 May 2021 08:19:00 GMT, Man Cao <manc at openjdk.org> wrote:

> If I understand the context correctly, the approach of updating the epoch counter in `process_if_requested_slow()` will prevent the pathological cases above? 

Yes, it will avoid that!

Thanks, Robbin

-------------

PR: https://git.openjdk.java.net/jdk/pull/4005

From github.com+4146708+a74nh at openjdk.java.net  Fri May 21 08:30:43 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 21 May 2021 08:30:43 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v2]
In-Reply-To: <2X6wKmdLVTsF2l-hCMK9ADl3cVNZEnsvKL9mShhYEn0=.04e22225-4fe1-4c48-bd92-a1106d26ab10@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <xafunuiUzI5EiDXPrYfVT6uh8sxgAG5ZspYD015JCqU=.57f2db72-71a8-4b71-84b7-be18f9522676@github.com>
 <sL17KDYLFhcxAM0lJGhxwuLbwbbM7Ke-p7Lkq5FNA2Y=.16565590-cd88-4be8-9883-dbcc5e27b2de@github.com>
 <7gEM1aNO-ZZEYc4p6en6PgcDoEjXe8lq-XYGSsTFl6c=.6df45640-716f-47f3-a251-2b3e775a62a4@github.com>
 <2X6wKmdLVTsF2l-hCMK9ADl3cVNZEnsvKL9mShhYEn0=.04e22225-4fe1-4c48-bd92-a1106d26ab10@github.com>
Message-ID: <-F-aIv2HeQ31mpJUFvEIMT557kNxnC0e0vshRHRBfLk=.2ae1e422-6df4-4f90-862f-b4de43af3cf0@github.com>

On Thu, 20 May 2021 21:35:42 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> For the values being stripped in this patch, they will always be return addresses saved on the stack. My first choice here was ptrauth_key_return_address, but I wanted it to be a little more generic and:
>> ptrauth_key_return_address = ptrauth_key_process_dependent_code = ptrauth_key_asib [1]
>> 
>> For a strip function, the key shouldn't matter as xpaci/xaplri instructions work for both IA and IB keys. However when I've dumped my test binaries on mac, it looked like the compiler used generic bitmasking instead of the xpac instructions. So it's possible the relevant key does matter here. Using the IB key ensures ptrauth_strip() always does the stripping (according to ptrauth.h comments), which is probably the safest option for now. I suspect full mac arm64e support would eventually require having multiple strip functions (pauth_strip_retaddr(), pauth_strip_functptr(), etc)
>> 
>> [1] https://opensource.apple.com/source/xnu/xnu-4903.241.1/EXTERNAL_HEADERS/ptrauth.h.auto.html
>
> I don't 100% understand this piece of code on macOS (I stripped non macOS code from it for clarity):
> 
> 
> inline address pauth_strip_pointer(address ptr) {
>    ptrauth_strip(ptr, ptrauth_key_asib);
>    return ptr;
>  }
> 
> 
> shouldn't it be something more like:
> 
> 
> inline address pauth_strip_pointer(address ptr) {
>    return ptrauth_strip(ptr, ptrauth_key_asib);
>  }
> 
> 
> or
> 
> 
> inline address pauth_strip_pointer(address ptr) {
>    ptr = ptrauth_strip(ptr, ptrauth_key_asib);
>    return ptr;
>  }
> 
> The original code compiles with **"Expression result unused"** for me.

Good spot. I'll fix this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From xliu at openjdk.java.net  Fri May 21 08:32:48 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 08:32:48 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <0RBAxMtNi1ijjnSACAun3B3aasxtaM8TGLBqMBj4TF4=.8109adf8-7bb0-4124-b7fe-5492626c4185@github.com>

On Fri, 21 May 2021 05:18:14 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 according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 76:
> 
>> 74: 
>> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.
>> 76: // the mutex here gurantees its integrity.
> 
> typo: gurantees -> guarantees

Reminder for myself: should replace Mutex with lock.  Implementation has changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From stefank at openjdk.java.net  Fri May 21 09:11:09 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 21 May 2021 09:11:09 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Clean up assembler_<cpu>.inline.hpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/6f3fe6af..260c1115

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=00-01

  Stats: 45 lines in 28 files changed: 3 ins; 24 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From ayang at openjdk.java.net  Fri May 21 10:09:39 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 May 2021 10:09:39 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
Message-ID: <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>

On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewer's feedback.

src/hotspot/share/logging/logAsyncWriter.cpp line 155:

> 153:   }
> 154: 
> 155:   assert(_state == ThreadState::Terminated, "sanity check");

I can't seem to find where `_state` is set to `ThreadState::Terminated` in this PR.

src/hotspot/share/logging/logAsyncWriter.cpp line 167:

> 165:     AsyncLogWriter* self = new AsyncLogWriter();
> 166: 
> 167:     if (self->_state == ThreadState::Initialized) {

The content of this `if` could be inlined to the constructor, and `ThreadState::Initialized` could be removed then, right?

src/hotspot/share/logging/logFileOutput.cpp line 312:

> 310:   if (aio_writer != nullptr) {
> 311:     aio_writer->enqueue(*this, decorations, msg);
> 312:     return -1;

Any difference between returning 0 and -1 here? Could you add some comments if any?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From vkempik at openjdk.java.net  Fri May 21 10:24:31 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 21 May 2021 10:24:31 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
In-Reply-To: <GL5ZbNppEW13hrK7FTSLkbzfqeAJLlO0xodXX_B10_E=.d8d81a6b-694a-424a-988c-431afb69c709@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <AmZDRftMKetPMwpyhCmEG5oB8gLZRQT8Mtmn4MKtqPg=.65f014a6-a023-4968-88d2-cb09d0e50a0f@github.com>
 <oKv9Wz6-knCjz8FQJHLyeFumLz9bNCegEr_KxPrN71A=.bf5500e6-f78c-4a29-8a14-0b4eb5f1a06a@github.com>
 <Rw1PE2-qYQ8J4SojgJ0UKa1m71wxeAkelWaS54TJIGg=.6c788d70-2afe-4545-b72f-aa39002a9b16@github.com>
 <GL5ZbNppEW13hrK7FTSLkbzfqeAJLlO0xodXX_B10_E=.d8d81a6b-694a-424a-988c-431afb69c709@github.com>
Message-ID: <sM-UEZGD7cDJyWXWlh5tM27XDL-MwtVbshgEX5x3Ivg=.285fba69-2775-4978-afa1-93f43100eb6b@github.com>

On Fri, 14 May 2021 16:52:30 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > It might be worth copying the assert I added to the linux_aarch64 version of fetch_compiled_frame_from_context() into the os_bsd version. That might catch what your seeing earlier. (Happy to add that to my patch too).
> 
> I have tried that and few more things, nothing catches that, only clearing upper 28 bits in c_rarg1 in generate_forward_exception helps. pauth_ptr_is_raw doesn't think it's pac-ed ptr ( maybe it always returns true on arm64 ( not arm64e))
> 
> here is example of ptrs on one run
> 
> return_address must be a return address: 0x9221800138009a5c
> return_address must be a return address: 0x5c08800138009a5c
> return_address must be a return address: 0x5c08800138009a5c
> return_address must be a return address: 0x8713800138009a5c
> return_address must be a return address: 0x0514800138009a5c
> return_address must be a return address: 0x8d7a000138009a5c
> return_address must be a return address: 0x403c000138009a5c
> return_address must be a return address: 0x492d000138009a5c
> return_address must be a return address: 0x403c000138009a5c
> 
> This is not any suggestion for this PR, just FYI

Turned out it was yet another PAC issue, fixed now for aarch64 (see JDK-8267235)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Fri May 21 11:07:14 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 21 May 2021 11:07:14 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:

  Ensure pointer is stripped on macos
  
  Change-Id: Idcf5f08e87c1e1f5af1dc8f421f8c7efc3d9c4c2
  CustomizedGitHooks: yes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4029/files
  - new: https://git.openjdk.java.net/jdk/pull/4029/files/386ee4e9..e7b220cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4029.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4029/head:pull/4029

PR: https://git.openjdk.java.net/jdk/pull/4029

From sjohanss at openjdk.java.net  Fri May 21 14:06:20 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 21 May 2021 14:06:20 GMT
Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux
 [v39]
In-Reply-To: <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
 <8Gn90ik2qJmP1zg3ttDhJmAMrImDHzIjMvJolNQ-TvI=.72c9117e-1d73-4715-b401-9c70f6ffe892@github.com>
Message-ID: <cI1eyYsSE3CHrsrqK88Im0f31bxdIkpLFZNnLxGzqXg=.27f29b45-e166-4c7c-ad94-7f213511a8fc@github.com>

On Thu, 20 May 2021 15:47:33 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tstuefe review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

I've done the final testing and it looks good. The testing in out CI doesn't show any new failures and my manual runs testing different page sizes also looks good. We have a few tests that needs to be fixed to be run with 1g pages, but that is not new with this patch. So I consider this ready for integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From thartmann at openjdk.java.net  Fri May 21 14:06:32 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 May 2021 14:06:32 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v9]
In-Reply-To: <PqaKCsAvDdmFfg1vcTvjG5DEjwjajKWD0J1PRPzbYLA=.81406790-be0c-41dd-b278-6af3fb52157e@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <PqaKCsAvDdmFfg1vcTvjG5DEjwjajKWD0J1PRPzbYLA=.81406790-be0c-41dd-b278-6af3fb52157e@github.com>
Message-ID: <BSVbQIalhrfFBUug1-G2CAGVU-mR59GcQ9e_BWoeke0=.03fba86a-2313-429c-8961-2e8cb7cec89b@github.com>

On Tue, 4 May 2021 15:53:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Splitting classes into subpackages and updating README accordingly, fix bug with new line matching in lookbehind on Windows
>  - Fix package names and fixing internal tests, examples and README file accordingly
>  - Move framework to test/hotspot/jtreg/compiler/lib and tests to test/hotspot/jtreg/testlibrary_tests/compiler/lib/ir_framework

Changes requested by thartmann (Reviewer).

test/hotspot/jtreg/compiler/lib/ir_framework/CompLevel.java line 70:

> 68:      *  </ul>
> 69:      */
> 70:     ANY(-2),

After the removal of AOT, this should be `-1`.

test/hotspot/jtreg/compiler/lib/ir_framework/Compiler.java line 37:

> 35:      * Selecting both the C1 and C2 compiler. This must be in sync with hotspot/share/compiler/compilerDefinitions.hpp.
> 36:      */
> 37:     ANY(-2),

After the removal of AOT, this should be `-1`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From mgkwill at openjdk.java.net  Fri May 21 14:24:05 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 21 May 2021 14:24:05 GMT
Subject: Integrated: 8256155: Allow multiple large page sizes to be used on
 Linux
In-Reply-To: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
References: <Sko_D6ZRMREOcNlqo66EuvHISa3MiD5vQJ5Xx0zx_M0=.abfb16f6-d7c0-4416-b05b-22bd5e1f748f@github.com>
Message-ID: <O5WE60ydhH-hGkalFGsx_9HHTtEFz5zik-YL0PB9AXA=.7c8d7066-5b7b-41b5-ad33-450c01dee27d@github.com>

On Wed, 11 Nov 2020 01:48:46 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

This pull request has now been integrated.

Changeset: 94cfeb9c
Author:    Marcus G K Williams <mgkwill at openjdk.org>
Committer: Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94cfeb9c4fee2ba5db8e5efa6b0f2041400c8b3a
Stats:     164 lines in 3 files changed: 101 ins; 43 del; 20 mod

8256155: Allow multiple large page sizes to be used on Linux

Co-authored-by: Marcus G K Williams <mgkwill at openjdk.org>
Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Co-authored-by: Thomas Stuefe <stuefe at openjdk.org>
Reviewed-by: stuefe, sjohanss

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153

From ayang at openjdk.java.net  Fri May 21 14:31:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 May 2021 14:31:12 GMT
Subject: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer
Message-ID: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>

Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

-------------

Commit messages:
 - alias map
 - second
 - first

Changes: https://git.openjdk.java.net/jdk/pull/4146/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4146&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267468
  Stats: 45 lines in 4 files changed: 2 ins; 0 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4146.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4146/head:pull/4146

PR: https://git.openjdk.java.net/jdk/pull/4146

From david.holmes at oracle.com  Fri May 21 14:32:17 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 22 May 2021 00:32:17 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <966833be-0e1e-c266-59b7-fc984aaf190f@oracle.com>

I ran this patch through our test system and the gtest is crashing in 
some cases:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/opt/mach5/mesos/work_dir/slaves/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S124159/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e6181b0d-b338-4338-8e7a-a969413802aa/runs/964cbe97-7c76-429e-a0cd-490459097714/workspace/open/src/hotspot/share/logging/logDecorations.cpp:78), 
pid=8163, tid=8179
#  assert(_decorators.is_decorator(decorator)) failed: decorator was not 
part of the decorator set specified at creation.
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 
17-internal+0-LTS-2021-05-21-0645591.david.holmes.jdk-dev4.git)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 
17-internal+0-LTS-2021-05-21-0645591.david.holmes.jdk-dev4.git, mixed 
mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x160ec44] 
LogDecorations::decoration(LogDecorators::Decorator, char*, unsigned 
long) const+0x94
#
# 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/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S79062/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e55170f3-f74b-45ca-955c-6c9f860f6f37/runs/b5e43087-b6d9-4d35-8001-49a0f73f47da/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.8163)
#
# 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: AMD EPYC 7J13 64-Core Processor, 12 cores, 46G, Oracle Linux 
Server release 7.9
Time: Fri May 21 07:01:05 2021 UTC elapsed time: 0.337971 seconds (0d 0h 
0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x000056160528bb20):  Thread [stack: 
0x00007f64a9d22000,0x00007f64a9e22000] [id=8179]

Stack: [0x00007f64a9d22000,0x00007f64a9e22000],  sp=0x00007f64a9e205e0, 
  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V  [libjvm.so+0x160ec44] 
LogDecorations::decoration(LogDecorators::Decorator, char*, unsigned 
long) const+0x94
V  [libjvm.so+0x1611a67]  LogFileStreamOutput::write(LogDecorations 
const&, char const*)+0x77
V  [libjvm.so+0x1610d42]  LogFileOutput::write_blocking(LogDecorations 
const&, char const*)+0x32
V  [libjvm.so+0x160b328]  AsyncLogWriter::perform_IO() [clone 
.constprop.0]+0x348
V  [libjvm.so+0x160b4d0]  AsyncLogWriter::run()+0x70
V  [libjvm.so+0x1c11800]  Thread::call_run()+0x100
V  [libjvm.so+0x18e8c7e]  thread_native_entry(Thread*)+0x10e


David
-----

On 21/05/2021 4:24 pm, David Holmes wrote:
> On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>> underlying files periodically.
>>
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update according to reviewer's feedback.
> 
> Overall I think this has shaped up rather well - thank you!
> 
> Hard for me to fully grok everything by reading the code though so I've requested a summary of operation comment in the header file.
> 
> Otherwise minor, mostly grammatical, comments.
> 
> Thanks,
> David
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 75:
> 
>> 73: }
>> 74:
>> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.
> 
> typo: messages -> message
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 76:
> 
>> 74:
>> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.
>> 76: // the mutex here gurantees its integrity.
> 
> typo: gurantees -> guarantees
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 118:
> 
>> 116: };
>> 117:
>> 118: void AsyncLogWriter::perform_IO() {
> 
> Seems to be all O and no I :)
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 164:
> 
>> 162:   if (!LogConfiguration::is_async_mode()) return;
>> 163:
>> 164:   if (_instance == nullptr) {
> 
> This method should only be called once so _instance must be NULL. An assert rather than an if would suffice.
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 175:
> 
>> 173:         ts->wait_until_no_readers();
>> 174:       }
>> 175:       self->_state = ThreadState::Running;
> 
> This seems like something the thread itself should do at the start of run()
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 177:
> 
>> 175:       self->_state = ThreadState::Running;
>> 176:       os::start_thread(self);
>> 177:       log_debug(logging, thread)("AsyncLogging starts working.");
> 
> Suggest: "Async logging thread started"
> 
> src/hotspot/share/logging/logAsyncWriter.cpp line 179:
> 
>> 177:       log_debug(logging, thread)("AsyncLogging starts working.");
>> 178:     } else {
>> 179:       log_warning(logging, thread)("AsyncLogging failed to launch thread. fall back to synchronous logging.");
> 
> "Async logging failed to create thread. Falling back to synchronous logging."
> 
> Shouldn't this be done where the os::create_thread failed though?
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 25:
> 
>> 23:  */
>> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
>> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP
> 
> Typos: WTRITER
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 34:
> 
>> 32: #include "utilities/hashtable.hpp"
>> 33: #include "utilities/linkedlist.hpp"
>> 34:
> 
> Could you write a summary of operation comment explaining how async mode works e.g.  details on initialization and teardown, how the thread interacts with writers etc. Thanks.
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 113:
> 
>> 111: typedef KVHashtable<LogFileOutput*, uint32_t, mtLogging> AsyncLogMap;
>> 112:
>> 113: class AsyncLogWriter: public NonJavaThread {
> 
> Any reason this is not a NamedThread? How will this appear in thread-dumps and crash reports?
> 
> Also I would have expected two classes to simplify the APIs: AsyncLogWriter and AsyncLogThread
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 115:
> 
>> 113: class AsyncLogWriter: public NonJavaThread {
>> 114:   static AsyncLogWriter* _instance;
>> 115:   static Semaphore _sem;
> 
> What is this semaphore for? A comment and/or a more meaningful name would be good.
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 125:
> 
>> 123:
>> 124:   volatile ThreadState _state;
>> 125:   AsyncLogMap _stats; // statistics of dropping messages.
> 
> // statistics for dropped messages
> 
> src/hotspot/share/logging/logAsyncWriter.hpp line 147:
> 
>> 145:
>> 146:   // None of following functions are thread-safe.
>> 147:   static AsyncLogWriter* instance();
> 
> instance() isn't thread-safe ??
> 
> src/hotspot/share/logging/logConfiguration.cpp line 555:
> 
>> 553:                                     " This will cause existing log files to be overwritten.");
>> 554:   out->cr();
>> 555:   out->print_cr("\nAsynchronous logging(off by default):");
> 
> space before "(off"
> 
> src/hotspot/share/runtime/globals.hpp line 1993:
> 
>> 1991:                                                                             \
>> 1992:   product(size_t, AsyncLogBufferSize, 2*M,                                  \
>> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \
> 
> space before (
> 
> src/hotspot/share/runtime/globals.hpp line 1995:
> 
>> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \
>> 1994:           "Logging (-Xlog:async).")                                         \
>> 1995:           range(100*K, 50*M)                                                \
> 
> What is the basis for this range?
> 
> src/hotspot/share/runtime/init.cpp line 127:
> 
>> 125:     return status;
>> 126:
>> 127:   AsyncLogWriter::initialize();
> 
> So prior to this point logging has been synchronous and now we switch if async-mode?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From xliu at openjdk.java.net  Fri May 21 16:48:12 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 16:48:12 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
Message-ID: <6GePBy4_JsFXb4IXt9VyLxsNdSDLBEYZEeHhbJEXvgc=.94c59bc8-8aeb-4944-8ddf-e5ba6802451b@github.com>

On Fri, 21 May 2021 09:43:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewer's feedback.
>
> src/hotspot/share/logging/logFileOutput.cpp line 312:
> 
>> 310:   if (aio_writer != nullptr) {
>> 311:     aio_writer->enqueue(*this, decorations, msg);
>> 312:     return -1;
> 
> Any difference between returning 0 and -1 here? Could you add some comments if any?

This is interesting! Thanks for the comment. 
I take a look at logFileStreamOuptut.cpp again, `LogFileStreamOutput::write` returns -1 when it runs into some errors. 

I feel it's more appropriate to return 0 here.  The value suggests that 'succeed but the written bytes is unknown.'
so far,  it doesn't matter because nobody reads this return value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Fri May 21 17:21:09 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 17:21:09 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
Message-ID: <WS7Tpb2NACyluu6K9o4ozhIPsQ6aIONJXdeF3TXHXTg=.fa0b2622-fc6a-41ec-8ef6-c28bbebe0151@github.com>

On Fri, 21 May 2021 09:54:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 167:
> 
>> 165:     AsyncLogWriter* self = new AsyncLogWriter();
>> 166: 
>> 167:     if (self->_state == ThreadState::Initialized) {
> 
> The content of this `if` could be inlined to the constructor, and `ThreadState::Initialized` could be removed then, right?

but it's not exceptional safe. I know hotspot doesn't use c++ exception, but the general principle still applys. 
the more logics in ctor, the more likely to fail.  So far, if something wrong, I left self in state of `NotReady`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Fri May 21 17:33:10 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 17:33:10 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
Message-ID: <yY3IOMJo1JwTGzXVxciUex4ql2-MA_xj-991ksRo7B4=.e3c19b58-90f3-4b06-b640-6d56f20a810e@github.com>

On Fri, 21 May 2021 09:13:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 155:
> 
>> 153:   }
>> 154: 
>> 155:   assert(_state == ThreadState::Terminated, "sanity check");
> 
> I can't seem to find where `_state` is set to `ThreadState::Terminated` in this PR.

Yes, it's another historical problem. I used to have AsyncLogWriter::terminate(), but Thomas said I can avoid the complexity by leaving it alone. 

remove if not in use?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
Message-ID: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From ayang at openjdk.java.net  Fri May 21 18:38:31 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 May 2021 18:38:31 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <yY3IOMJo1JwTGzXVxciUex4ql2-MA_xj-991ksRo7B4=.e3c19b58-90f3-4b06-b640-6d56f20a810e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
 <yY3IOMJo1JwTGzXVxciUex4ql2-MA_xj-991ksRo7B4=.e3c19b58-90f3-4b06-b640-6d56f20a810e@github.com>
Message-ID: <i5Ppfud74YZlminF8r_y040QHS9Pd4XBTrFFW436IFY=.b1d49457-9b43-415d-bed6-9024929f8e93@github.com>

On Fri, 21 May 2021 17:29:47 GMT, Xin Liu <xliu at openjdk.org> wrote:

> remove if not in use?

Yes, please.

Shouldn't this assertion be triggered as it is now? Why no failing tests?

>> src/hotspot/share/logging/logFileOutput.cpp line 312:
>> 
>>> 310:   if (aio_writer != nullptr) {
>>> 311:     aio_writer->enqueue(*this, decorations, msg);
>>> 312:     return -1;
>> 
>> Any difference between returning 0 and -1 here? Could you add some comments if any?
>
> This is interesting! Thanks for the comment. 
> I take a look at logFileStreamOuptut.cpp again, `LogFileStreamOutput::write` returns -1 when it runs into some errors. 
> 
> I feel it's more appropriate to return 0 here.  The value suggests that 'succeed but the written bytes is unknown.'
> so far,  it doesn't matter because nobody reads this return value.

I see; `0` seems better then. Thanks for the clarification.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From ayang at openjdk.java.net  Fri May 21 18:46:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 May 2021 18:46:42 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <WS7Tpb2NACyluu6K9o4ozhIPsQ6aIONJXdeF3TXHXTg=.fa0b2622-fc6a-41ec-8ef6-c28bbebe0151@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
 <WS7Tpb2NACyluu6K9o4ozhIPsQ6aIONJXdeF3TXHXTg=.fa0b2622-fc6a-41ec-8ef6-c28bbebe0151@github.com>
Message-ID: <njzzb2AxwZ8-8TeHHEKalqsfAB2OJLJOueJDXgCjOGU=.68ddc2f5-7e31-49c1-89d7-4b6511a48c84@github.com>

On Fri, 21 May 2021 17:17:36 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 167:
>> 
>>> 165:     AsyncLogWriter* self = new AsyncLogWriter();
>>> 166: 
>>> 167:     if (self->_state == ThreadState::Initialized) {
>> 
>> The content of this `if` could be inlined to the constructor, and `ThreadState::Initialized` could be removed then, right?
>
> but it's not exceptional safe. I know hotspot doesn't use c++ exception, but the general principle still applys. 
> the more logics in ctor, the more likely to fail.  So far, if something wrong, I left self in state of `NotReady`.

Since hotspot does not use c++ exception, I don't really follow the reasoning of "the more logics in ctor, the more likely to fail". Code doesn't just fail mysteriously. The only thing that could "fail" here is `new AsyncLogWriter()` returns `nullptr`, I think.

Anyway, this is just a suggestion; feel free to go for the style you prefer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xxinliu at amazon.com  Fri May 21 19:00:45 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Fri, 21 May 2021 12:00:45 -0700
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <966833be-0e1e-c266-59b7-fc984aaf190f@oracle.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
 <966833be-0e1e-c266-59b7-fc984aaf190f@oracle.com>
Message-ID: <d65a87ca-e3f2-4391-bfc2-7d38869a8e94@amazon.com>

hi, David,

I am aware of this issue. There are a few gtest testcases can't run in
async logging mode. The rootcause is testing code assumes logging is
synchronous.

eg. this testcase opens and reads 'TestLogFileName' right after
log_trace(). This is perfectly fine in sequential execution. It's unsafe
and TestLogFileName may haven't been written yet. fopen could fail(no
error check in current testing) and then fread yields NULL pointer for
strcmp.

TEST_VM_F(LogTest, prefix) {
  set_log_config(TestLogFileName, "logging+test=trace");
  log_trace(logging, test)(LOG_LINE_STR);
  EXPECT_TRUE(file_contains_substring(TestLogFileName, LOG_PREFIX_STR
LOG_LINE_STR));
}

It's also not MT-safe to do concurrent fread() (gtest EXPECT/ASSERT)
while fwrite is onging(AsyncLog Thread). Random execution may happen if
 FILE has been corrupted.


I manage to fix those hard crashes in gtests. It would up a non-trivial
patch, and it just fixed hard crashes. I reckon I give up running gtest
in async mode and provide an isolated and a clean room to test it.
https://github.com/openjdk/jdk/pull/3135/files#diff-81543b39e56eafc7fc7184d4334ad7b68ed1574b38eba158be2d065e4b35e42f

If you insist no hard crash would happen in gtest, how about I create a
separated issue and send that PR for review?

Technically, I can even make thoses failed testcases pass in async mode.
All I need to do is to insert AsyncLogWriter::flush() in paranoid mode.
That would ruin the readability of the existing tests.

FYI, not only gtest, there's one intermitten failure in jtreg-tier1 if
async logging is on. 'serviceability/dcmd/gc/RunGCTest.java'. The reason
is still lack of synchronization. This test uses dcmd 'GC.run' to
trigger a gc activity and expect to see logs. sometimes it fails to
capture the logs.

thanks,
--lx



On 5/21/21 7:32 AM, 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.
> 
> 
> 
> I ran this patch through our test system and the gtest is crashing in
> some cases:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error
> (/opt/mach5/mesos/work_dir/slaves/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S124159/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e6181b0d-b338-4338-8e7a-a969413802aa/runs/964cbe97-7c76-429e-a0cd-490459097714/workspace/open/src/hotspot/share/logging/logDecorations.cpp:78),
> pid=8163, tid=8179
> #  assert(_decorators.is_decorator(decorator)) failed: decorator was not
> part of the decorator set specified at creation.
> #
> # JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build
> 17-internal+0-LTS-2021-05-21-0645591.david.holmes.jdk-dev4.git)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug
> 17-internal+0-LTS-2021-05-21-0645591.david.holmes.jdk-dev4.git, mixed
> mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x160ec44]
> LogDecorations::decoration(LogDecorators::Decorator, char*, unsigned
> long) const+0x94
> #
> # 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/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S79062/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e55170f3-f74b-45ca-955c-6c9f860f6f37/runs/b5e43087-b6d9-4d35-8001-49a0f73f47da/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/scratch/0/core.8163)
> #
> # 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: AMD EPYC 7J13 64-Core Processor, 12 cores, 46G, Oracle Linux
> Server release 7.9
> Time: Fri May 21 07:01:05 2021 UTC elapsed time: 0.337971 seconds (0d 0h
> 0m 0s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x000056160528bb20):  Thread [stack:
> 0x00007f64a9d22000,0x00007f64a9e22000] [id=8179]
> 
> Stack: [0x00007f64a9d22000,0x00007f64a9e22000],  sp=0x00007f64a9e205e0,
>   free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V  [libjvm.so+0x160ec44]
> LogDecorations::decoration(LogDecorators::Decorator, char*, unsigned
> long) const+0x94
> V  [libjvm.so+0x1611a67]  LogFileStreamOutput::write(LogDecorations
> const&, char const*)+0x77
> V  [libjvm.so+0x1610d42]  LogFileOutput::write_blocking(LogDecorations
> const&, char const*)+0x32
> V  [libjvm.so+0x160b328]  AsyncLogWriter::perform_IO() [clone
> .constprop.0]+0x348
> V  [libjvm.so+0x160b4d0]  AsyncLogWriter::run()+0x70
> V  [libjvm.so+0x1c11800]  Thread::call_run()+0x100
> V  [libjvm.so+0x18e8c7e]  thread_native_entry(Thread*)+0x10e
> 
> 
> David
> -----
> 
> On 21/05/2021 4:24 pm, David Holmes wrote:
>> On Thu, 20 May 2021 09:08:04 GMT, Xin Liu <xliu at openjdk.org> wrote:
>>
>>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>>> underlying files periodically.
>>>
>>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Update according to reviewer's feedback.
>>
>> Overall I think this has shaped up rather well - thank you!
>>
>> Hard for me to fully grok everything by reading the code though so I've requested a summary of operation comment in the header file.
>>
>> Otherwise minor, mostly grammatical, comments.
>>
>> Thanks,
>> David
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 75:
>>
>>> 73: }
>>> 74:
>>> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.
>>
>> typo: messages -> message
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 76:
>>
>>> 74:
>>> 75: // LogMessageBuffer consists of a multiple-part/multiple-line messsages.
>>> 76: // the mutex here gurantees its integrity.
>>
>> typo: gurantees -> guarantees
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 118:
>>
>>> 116: };
>>> 117:
>>> 118: void AsyncLogWriter::perform_IO() {
>>
>> Seems to be all O and no I :)
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 164:
>>
>>> 162:   if (!LogConfiguration::is_async_mode()) return;
>>> 163:
>>> 164:   if (_instance == nullptr) {
>>
>> This method should only be called once so _instance must be NULL. An assert rather than an if would suffice.
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 175:
>>
>>> 173:         ts->wait_until_no_readers();
>>> 174:       }
>>> 175:       self->_state = ThreadState::Running;
>>
>> This seems like something the thread itself should do at the start of run()
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 177:
>>
>>> 175:       self->_state = ThreadState::Running;
>>> 176:       os::start_thread(self);
>>> 177:       log_debug(logging, thread)("AsyncLogging starts working.");
>>
>> Suggest: "Async logging thread started"
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 179:
>>
>>> 177:       log_debug(logging, thread)("AsyncLogging starts working.");
>>> 178:     } else {
>>> 179:       log_warning(logging, thread)("AsyncLogging failed to launch thread. fall back to synchronous logging.");
>>
>> "Async logging failed to create thread. Falling back to synchronous logging."
>>
>> Shouldn't this be done where the os::create_thread failed though?
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 25:
>>
>>> 23:  */
>>> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
>>> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP
>>
>> Typos: WTRITER
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 34:
>>
>>> 32: #include "utilities/hashtable.hpp"
>>> 33: #include "utilities/linkedlist.hpp"
>>> 34:
>>
>> Could you write a summary of operation comment explaining how async mode works e.g.  details on initialization and teardown, how the thread interacts with writers etc. Thanks.
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 113:
>>
>>> 111: typedef KVHashtable<LogFileOutput*, uint32_t, mtLogging> AsyncLogMap;
>>> 112:
>>> 113: class AsyncLogWriter: public NonJavaThread {
>>
>> Any reason this is not a NamedThread? How will this appear in thread-dumps and crash reports?
>>
>> Also I would have expected two classes to simplify the APIs: AsyncLogWriter and AsyncLogThread
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 115:
>>
>>> 113: class AsyncLogWriter: public NonJavaThread {
>>> 114:   static AsyncLogWriter* _instance;
>>> 115:   static Semaphore _sem;
>>
>> What is this semaphore for? A comment and/or a more meaningful name would be good.
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 125:
>>
>>> 123:
>>> 124:   volatile ThreadState _state;
>>> 125:   AsyncLogMap _stats; // statistics of dropping messages.
>>
>> // statistics for dropped messages
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 147:
>>
>>> 145:
>>> 146:   // None of following functions are thread-safe.
>>> 147:   static AsyncLogWriter* instance();
>>
>> instance() isn't thread-safe ??
>>
>> src/hotspot/share/logging/logConfiguration.cpp line 555:
>>
>>> 553:                                     " This will cause existing log files to be overwritten.");
>>> 554:   out->cr();
>>> 555:   out->print_cr("\nAsynchronous logging(off by default):");
>>
>> space before "(off"
>>
>> src/hotspot/share/runtime/globals.hpp line 1993:
>>
>>> 1991:                                                                             \
>>> 1992:   product(size_t, AsyncLogBufferSize, 2*M,                                  \
>>> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \
>>
>> space before (
>>
>> src/hotspot/share/runtime/globals.hpp line 1995:
>>
>>> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \
>>> 1994:           "Logging (-Xlog:async).")                                         \
>>> 1995:           range(100*K, 50*M)                                                \
>>
>> What is the basis for this range?
>>
>> src/hotspot/share/runtime/init.cpp line 127:
>>
>>> 125:     return status;
>>> 126:
>>> 127:   AsyncLogWriter::initialize();
>>
>> So prior to this point logging has been synchronous and now we switch if async-mode?
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3135
>>

From simonis at openjdk.java.net  Fri May 21 19:29:17 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 21 May 2021 19:29:17 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after 8238048
Message-ID: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>

In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.

This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 

In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.

The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).

I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:

  // Copy the "source file name" attribute from new class version
  the_class->set_source_file_name_index(
    scratch_class->source_file_name_index());

Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

-------------

Commit messages:
 - 8267555: Fix class file version during redefinition after 8238048

Changes: https://git.openjdk.java.net/jdk/pull/4149/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267555
  Stats: 258 lines in 6 files changed: 251 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4149/head:pull/4149

PR: https://git.openjdk.java.net/jdk/pull/4149

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: <UgO9-C6Oo_ulIRbQWW6Jw5HEPeJHSAnpgfdXEfiQVNE=.bf8a2656-e9bf-4627-a37b-cc9ca84e6d1b@github.com>

On Fri, 21 May 2021 18:26:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From paul.sandoz at oracle.com  Fri May 21 20:00:42 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 21 May 2021 20:00:42 +0000
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support
In-Reply-To: <7710bb66-0712-66cb-7ffc-1559975d6394@arm.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <B2D38C5E-8F40-484C-98DF-45F985B0E85C@oracle.com>
 <7710bb66-0712-66cb-7ffc-1559975d6394@arm.com>
Message-ID: <A7117A80-E53C-4CF5-82B6-FF2290958705@oracle.com>

Hi Ningsheng,

Thanks for your understanding. I shall work towards a new draft JEP soon after 17 RDP 1.

Paul.

> On May 20, 2021, at 7:16 PM, Ningsheng Jian <Ningsheng.Jian at arm.com> wrote:
> 
> Hi Paul,
> 
> Thanks for the clarification about JEP process.
> 
> On 5/21/21 6:30 AM, Paul Sandoz wrote:
>> Hi Ningsheng,
>> Thank you for doing this work and preparing a review.
>> We might have our wires crossed a little with regards to JEPs, or we just need to clarify the intent.
>> I think this important work needs to be part of a Vector API JEP, it being a relevant new feature (in this case with a large contribution of code). That approach has been applied to the SVML support on x86 which is currently part of JEP 414, in addition to the API enhancements. I don?t think we can skip the JEP process for such a feature, and especially so since this is an incubating feature.
>> The reason I did not included SVE support in JEP 414, as we discussed, was because it may be too late to get the code properly reviewed in time by 17 RDP 1 (feature freeze on 2021/06/10).
>> (Note that JEP 414 currently explicitly calls out SVE support as future work.)
>> It's not that the JEP process takes time, it's that code reviews can take time, especially closer to RDP 1 as reviewers are often very busy.
>> If you and the reviewers think the code can be reviewed by 17 RDP 1 then we can update JEP 414 and include it. But, I strongly recommend we should include it in a further JEP we can plan and propose to target for 18 (I can prepare a new draft JEP after JEP 414 integrates).
> 
> Agree that this SVE support feature needs to be included in Vector API JEP. I am not familiar with the JEP process, but it seems to me that updating JEP 414 at the last minute is risky. So, I am happy to defer the integration until 18, with another Vector API JEP.
> 
>> However, to be clear, that does not negate starting the code review process now as you have done, in fact that?s a good thing :-) being prepared for a proposed release early in that release cycle reduces risk and increases chances of integration.
> 
> Yes, review comments for this patch are welcome. :-) I have set the "Fix Version" to 18 in JBS.
> 
> Thanks,
> Ningsheng
> 
> 


From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <J7PKD_tgpaSH7oobcuRkh3qKFsr1wAPbxqEPaW7dJa0=.71e1df8c-8f2d-49b0-8a21-819907087678@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From xliu at openjdk.java.net  Fri May 21 20:28:13 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 20:28:13 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <i5Ppfud74YZlminF8r_y040QHS9Pd4XBTrFFW436IFY=.b1d49457-9b43-415d-bed6-9024929f8e93@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <e-8gEB8gttnrRaUYIN5q_b1k5aQzj0uaLqi0gU2adt4=.5f45f640-aa26-4b0d-a4f1-96f175e8a080@github.com>
 <yY3IOMJo1JwTGzXVxciUex4ql2-MA_xj-991ksRo7B4=.e3c19b58-90f3-4b06-b640-6d56f20a810e@github.com>
 <i5Ppfud74YZlminF8r_y040QHS9Pd4XBTrFFW436IFY=.b1d49457-9b43-415d-bed6-9024929f8e93@github.com>
Message-ID: <qa8wmpgS0XWPLdsVWnxrPa5o6GsVUpQ8uVALdDeQ5Ws=.81a073c6-2ffc-4456-aaf6-01fbb52ab8a0@github.com>

On Fri, 21 May 2021 18:28:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Yes, it's another historical problem. I used to have AsyncLogWriter::terminate(), but Thomas said I can avoid the complexity by leaving it alone. 
>> 
>> remove if not in use?
>
>> remove if not in use?
> 
> Yes, please.
> 
> Shouldn't this assertion be triggered as it is now? Why no failing tests?

it's because while (_state == ThreadState::Running) is a dead loop. 
Nobody attempts to terminate AsyncLog Thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
Message-ID: <S-kozOfLwraS98p1UoWwwNGs-M6kfUYjtcFVwtnFChY=.13224ab0-59c6-42b9-be32-46d2599b7acf@github.com>

On Fri, 21 May 2021 20:43:05 GMT, Phil Race <prr at openjdk.org> wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From xliu at openjdk.java.net  Fri May 21 20:57:12 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 20:57:12 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <yINr5TtMWo-AUvv3mLvif0mTs5Z4kPyZKZ_fDlix4wM=.5155250c-3051-4ac2-a772-a76f39b5d7b4@github.com>

On Fri, 21 May 2021 05:40:56 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 according to reviewer's feedback.
>
> src/hotspot/share/runtime/init.cpp line 127:
> 
>> 125:     return status;
>> 126: 
>> 127:   AsyncLogWriter::initialize();
> 
> So prior to this point logging has been synchronous and now we switch if async-mode?

yes, after the store of _instance is seen, all logs switch to async mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Fri May 21 22:13:09 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 21 May 2021 22:13:09 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <iyfJoXPX1To65xB40EkQ8b0dBdkrJoowDyb6TjHOiFc=.f6979d5f-9848-4374-ad26-c989bf7bb763@github.com>

On Fri, 21 May 2021 05:45:12 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 according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 113:
> 
>> 111: typedef KVHashtable<LogFileOutput*, uint32_t, mtLogging> AsyncLogMap;
>> 112: 
>> 113: class AsyncLogWriter: public NonJavaThread {
> 
> Any reason this is not a NamedThread? How will this appear in thread-dumps and crash reports?
> 
> Also I would have expected two classes to simplify the APIs: AsyncLogWriter and AsyncLogThread

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. 

I just figure out `Threads::print_on()` needs  special care for dumpthread.  Nice catch!
With my patch, it finally shows up. 

"AsyncLog Thread" os_prio=0 cpu=239.26ms elapsed=52.13s tid=0x00007fb814c76ec0 nid=0x9023 runnable


Now there are only 4 APIs for clients. Splitting up 2 classes seems not to simplify code a lot.

> src/hotspot/share/logging/logAsyncWriter.hpp line 147:
> 
>> 145: 
>> 146:   // None of following functions are thread-safe.
>> 147:   static AsyncLogWriter* instance();
> 
> instance() isn't thread-safe ??

yes, the comment is outdated.  This is MT-safe. 
I will update it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 00:49:07 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 00:49:07 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <8EOhNHpfxYzZ60eqO7kUH0DCN4Fxd3VZndgkYT2Q9a0=.c4ebb132-6d7b-4516-bf25-3bc168abb368@github.com>

On Fri, 21 May 2021 05:43:57 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 according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 25:
> 
>> 23:  */
>> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
>> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP
> 
> Typos: WTRITER

ack

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 01:03:29 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 01:03:29 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v18]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <cD27gLAWwCK29qQ2gqw3uHAMehNbGEAI84fB9wk2aLE=.2a9aeec5-6750-43c8-9de8-def80cf63297@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Add threadump support for AsyncLog Thread.
  
  when jstack requests to dump threads:
  "AsyncLog Thread" os_prio=0 cpu=239.26ms elapsed=52.13s tid=0x00007fb814c76ec0 nid=0x9023 runnable
  
  When jvm crash, thread dump is written to hs_err_pid$pid.log.
  0x00007fa8d824e450 Thread "AsyncLog Thread" [stack: 0x00007fa880d44000,0x00007fa880e44000] [id=126290]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/348edfc0..2381ba19

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=16-17

  Stats: 11 lines in 3 files changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 01:14:12 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 01:14:12 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <_RH8YpapEpdMG201y_jbUZtCLId30b5wZ4SWJR-yuvg=.2641d23d-c432-430d-a75e-f611b4772308@github.com>

On Fri, 21 May 2021 06:04: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:
>> 
>>   Update according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 118:
> 
>> 116: };
>> 117: 
>> 118: void AsyncLogWriter::perform_IO() {
> 
> Seems to be all O and no I :)

Let's call it "IO" for tradition. It would become more confusing if I changed it to `perform_O`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 01:34:12 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 01:34:12 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <db6uuVoLvf9J20m8FQcck4EX3oI3ugZJTXa93tcpY04=.bc30db13-b4f0-48a5-b16a-a7edfc8613d6@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <db6uuVoLvf9J20m8FQcck4EX3oI3ugZJTXa93tcpY04=.bc30db13-b4f0-48a5-b16a-a7edfc8613d6@github.com>
Message-ID: <QQPzaPA4BG01Fjp8TLxbbk_R_hi_YKs0sLjkwDZMzBI=.5ea45ea8-4b36-4146-84ea-b4c3dc1eff20@github.com>

On Thu, 20 May 2021 20:15:04 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 26:
> 
>> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
>> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP
>> 26: #include "logging/log.hpp"
> 
> Use SHARE_LOGGING_LOGASYNCHWRITER_HPP to conform with existing naming standard.

Oh, there's a hidden naming convention here. 
thanks for the head-up!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From david.holmes at oracle.com  Sat May 22 02:38:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 22 May 2021 12:38:43 +1000
Subject: invokeinterface on sealed interfaces
In-Reply-To: <CABe8uE3dqD_QUrmN8t=udUZ7Wp41cRRqC_O1+Gf9Ceh4GvhAeA@mail.gmail.com>
References: <CABe8uE3dqD_QUrmN8t=udUZ7Wp41cRRqC_O1+Gf9Ceh4GvhAeA@mail.gmail.com>
Message-ID: <efb88346-81e8-5360-6557-7ca8fc2e28f5@oracle.com>

Hi,

Probably something best discussed on hotspot-dev (cc'd) or perhaps 
hotspot-compiler-dev.

Disclaimer: I'm not a JIT expert. :)

On 22/05/2021 11:50 am, - wrote:
> Greetings all,
> I have heard of a myth against using interfaces, namely on how
> invokeinterface is slower than invokevirtual since concrete class methods
> to call, with known indices in the method table, can be found more easily
> than interface methods, which always require a lookup by name.

Not sure about that part.

> Another myth I've heard is that JVM may decide to construct a temporary
> table for interface dispatches as well, but the table would be discarded
> once another class is discovered in the interface hierarchy and the
> performance would slow back down.

This happens for classes and virtual methods too. Class Hierarchy 
Analysis (CHA) can be used to devirtualise a call-site if we know there 
can't be subclasses to distinguish. If a subclass is subsequently loaded 
then that analysis has to be discarded and the code deoptimised so the 
call site is virtualised again.

> I wonder if these two claims are right; unfortunately, I am no good at the
> VM internals and can't verify them. But if they are true, I wonder if
> invokeinterface calls on sealed interface methods would enjoy a performance
> boost and have its performance brought closer to that of invokevirtual
> calls. It seems that the sealed class design not only provides clearer
> apis, but also allow the VM to better optimize code.

I'm not sure if there is much scope for additional optimisation beyond 
the fact that if all subclasses are known when CHA is applied then we 
know it can't be invalidated later. JIT compiler folk may be able to say 
more.

Cheers,
David

> Best
> 

From david.holmes at oracle.com  Sat May 22 02:41:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 22 May 2021 12:41:31 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <_RH8YpapEpdMG201y_jbUZtCLId30b5wZ4SWJR-yuvg=.2641d23d-c432-430d-a75e-f611b4772308@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
 <_RH8YpapEpdMG201y_jbUZtCLId30b5wZ4SWJR-yuvg=.2641d23d-c432-430d-a75e-f611b4772308@github.com>
Message-ID: <1b03b363-1ebb-a566-b90b-4067cec7bbda@oracle.com>

On 22/05/2021 11:14 am, Xin Liu wrote:
> On Fri, 21 May 2021 06:04: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:
>>>
>>>    Update according to reviewer's feedback.
>>
>> src/hotspot/share/logging/logAsyncWriter.cpp line 118:
>>
>>> 116: };
>>> 117:
>>> 118: void AsyncLogWriter::perform_IO() {
>>
>> Seems to be all O and no I :)
> 
> Let's call it "IO" for tradition. It would become more confusing if I changed it to `perform_O`

You could just call it write() or writeToLogs() or outputToLogs() or ...

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From david.holmes at oracle.com  Sat May 22 02:42:23 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 22 May 2021 12:42:23 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <QQPzaPA4BG01Fjp8TLxbbk_R_hi_YKs0sLjkwDZMzBI=.5ea45ea8-4b36-4146-84ea-b4c3dc1eff20@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <db6uuVoLvf9J20m8FQcck4EX3oI3ugZJTXa93tcpY04=.bc30db13-b4f0-48a5-b16a-a7edfc8613d6@github.com>
 <QQPzaPA4BG01Fjp8TLxbbk_R_hi_YKs0sLjkwDZMzBI=.5ea45ea8-4b36-4146-84ea-b4c3dc1eff20@github.com>
Message-ID: <5edb2854-4160-8a82-bce4-89a1cfd7e7d0@oracle.com>

On 22/05/2021 11:34 am, Xin Liu wrote:
> On Thu, 20 May 2021 20:15:04 GMT, Paul Hohensee <phh at openjdk.org> wrote:
> 
>>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Update according to reviewer's feedback.
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 26:
>>
>>> 24: #ifndef SHARE_LOG_ASYNC_WTRITER_HPP
>>> 25: #define SHARE_LOG_ASYNC_WTRITER_HPP
>>> 26: #include "logging/log.hpp"
>>
>> Use SHARE_LOGGING_LOGASYNCHWRITER_HPP to conform with existing naming standard.
> 
> Oh, there's a hidden naming convention here.
> thanks for the head-up!

It's not hidden, it is the path + filename.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From vitalyd at gmail.com  Sat May 22 03:08:39 2021
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 21 May 2021 23:08:39 -0400
Subject: invokeinterface on sealed interfaces
In-Reply-To: <efb88346-81e8-5360-6557-7ca8fc2e28f5@oracle.com>
References: <CABe8uE3dqD_QUrmN8t=udUZ7Wp41cRRqC_O1+Gf9Ceh4GvhAeA@mail.gmail.com>
 <efb88346-81e8-5360-6557-7ca8fc2e28f5@oracle.com>
Message-ID: <CAHjP37Hg+NQeuB8mNxN5DLX9cLCofqiYY2SpDBhZxSwfj30xcg@mail.gmail.com>

https://wiki.openjdk.java.net/display/HotSpot/InterfaceCalls is an old but
(I believe) still accurate description of how invokeinterface is dispatched
(if not monomorphized by the JIT).  In short, it doesn?t look up the method
by name but it does walk the receiver (ie object on which method is being
invoked) class?s list of interfaces to ensure it implements the interface
in question.  Once found, there?s an itable (similar in concept to vtable)
associated with that class?s implementation of the interface.

As for the more general question around dispatch performance,
https://shipilev.net/blog/2015/black-magic-method-dispatch/ is a good
writeup by Aleksey.  While some things may look expensive (eg
invokeinterface), the high tier JITs typically do a good job of making them
more efficient, leveraging runtime callsite type profiling.

Hope that helps.

On Fri, May 21, 2021 at 10:39 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi,
>
> Probably something best discussed on hotspot-dev (cc'd) or perhaps
> hotspot-compiler-dev.
>
> Disclaimer: I'm not a JIT expert. :)
>
> On 22/05/2021 11:50 am, - wrote:
> > Greetings all,
> > I have heard of a myth against using interfaces, namely on how
> > invokeinterface is slower than invokevirtual since concrete class methods
> > to call, with known indices in the method table, can be found more easily
> > than interface methods, which always require a lookup by name.
>
> Not sure about that part.


>
> > Another myth I've heard is that JVM may decide to construct a temporary
> > table for interface dispatches as well, but the table would be discarded
> > once another class is discovered in the interface hierarchy and the
> > performance would slow back down.
>
> This happens for classes and virtual methods too. Class Hierarchy
> Analysis (CHA) can be used to devirtualise a call-site if we know there
> can't be subclasses to distinguish. If a subclass is subsequently loaded
> then that analysis has to be discarded and the code deoptimised so the
> call site is virtualised again.
>
> > I wonder if these two claims are right; unfortunately, I am no good at
> the
> > VM internals and can't verify them. But if they are true, I wonder if
> > invokeinterface calls on sealed interface methods would enjoy a
> performance
> > boost and have its performance brought closer to that of invokevirtual
> > calls. It seems that the sealed class design not only provides clearer
> > apis, but also allow the VM to better optimize code.
>
> I'm not sure if there is much scope for additional optimisation beyond
> the fact that if all subclasses are known when CHA is applied then we
> know it can't be invalidated later. JIT compiler folk may be able to say
> more.
>
> Cheers,
> David
>
> > Best
> >
>
-- 
Sent from my phone

From stuefe at openjdk.java.net  Sat May 22 04:50:15 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 22 May 2021 04:50:15 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v18]
In-Reply-To: <cD27gLAWwCK29qQ2gqw3uHAMehNbGEAI84fB9wk2aLE=.2a9aeec5-6750-43c8-9de8-def80cf63297@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <cD27gLAWwCK29qQ2gqw3uHAMehNbGEAI84fB9wk2aLE=.2a9aeec5-6750-43c8-9de8-def80cf63297@github.com>
Message-ID: <ESeNUwhGX0XqcXdK-dV3gclFwvLhdGcWawbeBa4P4Rw=.dd147e8a-89c7-4d9c-8351-2214b2ec5081@github.com>

On Sat, 22 May 2021 01:03:29 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add threadump support for AsyncLog Thread.
>   
>   when jstack requests to dump threads:
>   "AsyncLog Thread" os_prio=0 cpu=239.26ms elapsed=52.13s tid=0x00007fb814c76ec0 nid=0x9023 runnable
>   
>   When jvm crash, thread dump is written to hs_err_pid$pid.log.
>   0x00007fa8d824e450 Thread "AsyncLog Thread" [stack: 0x00007fa880d44000,0x00007fa880e44000] [id=126290]

> _Mailing list message from [Liu, Xin](mailto:xxinliu at amazon.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> hi, David,
> 
> I am aware of this issue. There are a few gtest testcases can't run in
> async logging mode. The rootcause is testing code assumes logging is
> synchronous.
> 
> eg. this testcase opens and reads 'TestLogFileName' right after
> log_trace(). This is perfectly fine in sequential execution. It's unsafe
> and TestLogFileName may haven't been written yet. fopen could fail(no
> error check in current testing) and then fread yields NULL pointer for
> strcmp.
> 
> TEST_VM_F(LogTest, prefix) {
> set_log_config(TestLogFileName, "logging+test=trace");
> log_trace(logging, test)(LOG_LINE_STR);
> EXPECT_TRUE(file_contains_substring(TestLogFileName, LOG_PREFIX_STR
> LOG_LINE_STR));
> }
> 
> It's also not MT-safe to do concurrent fread() (gtest EXPECT/ASSERT)
> while fwrite is onging(AsyncLog Thread). Random execution may happen if
> FILE has been corrupted.
> 
> I manage to fix those hard crashes in gtests. It would up a non-trivial
> patch, and it just fixed hard crashes. I reckon I give up running gtest
> in async mode and provide an isolated and a clean room to test it.

Hi Xin,

I agree that these UL tests are annoying because they modify global VM state - resetting global UL options which ideally should just be set at VM startup and then never touched. gtest should not do this.

I struggled with the same thing with NMT in this upcoming PR: https://github.com/openjdk/jdk/pull/2921.

As I wrote before, in my view, it should be possible to execute the gtest suite with any form of UL options - or VM options in general - and the gtests should at most *react* on those options, never change them. In the case of UL, maybe conditionally execute or skip some tests if UL is on or off. 

In other words, I should be able to run `gtestLauncher -jdk:... -Xlog:os` and the gtests should run through successfully with these flags. And then, as a complimentary step, we execute the gtests (or selected parts of them with --gtest_filter) with selected, non-default, VM options. E.g. with UL turned on. I know you do this already for some of the Async tests, and maybe thats the way to go for all UL gtests. We do this also for Metaspace- and large-page-tests. And I will modify the NMT gtests to not modify NMT state anymore:https://github.com/openjdk/jdk/pull/2921/files#diff-c1004f2502ccc5f5340e7752264c7e0274f6a5fe4da0554d89d3bc8209801199 )

Moreover, things like "log to a file and scan for expected output" are really better suited for jtreg tests anyway, which spawn a child VM with options and scan the log output. Doing this in gtests seems wrong. Jtreg gives more fine-grained control, I can `-retain` the output files, I can execute them in parallel, Problemlist them, etc. I don't have to execute test logic like reading the log output file *inside* the logging VM.

So maybe (future RFE?) we need to move part or all of the UL tests out of the gtest suite and make them jtreg tests. 

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From kbarrett at openjdk.java.net  Sat May 22 05:53:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 22 May 2021 05:53:59 GMT
Subject: RFR: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <L2rUpy9F2WBGBToBTsS3S_WC5Up8-RntBVinIFoRxMo=.b814ca68-e271-49a8-a90c-a6bdf019cac0@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4146

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
 <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
Message-ID: <EY0wxSpTN5BT63blVVvIHQ69tvBmgDTXcSroIDhlhcA=.2e93e74b-33e5-444e-8bcb-c8ffc3621597@github.com>

On Fri, 21 May 2021 18:00:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From xliu at openjdk.java.net  Sat May 22 08:04:08 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 08:04:08 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <_RH8YpapEpdMG201y_jbUZtCLId30b5wZ4SWJR-yuvg=.2641d23d-c432-430d-a75e-f611b4772308@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
 <_RH8YpapEpdMG201y_jbUZtCLId30b5wZ4SWJR-yuvg=.2641d23d-c432-430d-a75e-f611b4772308@github.com>
Message-ID: <qcwZ77Uwt-htXM_zj4LA7Q9b2_LMfWP39_dtMtzlcxo=.575b177c-2eee-478c-a220-37797f646232@github.com>

On Sat, 22 May 2021 01:11:00 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 118:
>> 
>>> 116: };
>>> 117: 
>>> 118: void AsyncLogWriter::perform_IO() {
>> 
>> Seems to be all O and no I :)
>
> Let's call it "IO" for tradition. It would become more confusing if I changed it to `perform_O`

okay. change it to 'write()'

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 08:44:08 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 08:44:08 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <5AQGVnlqrW_WaFMNY_RQzPezrdOJ4yqkB4E-awNvHPk=.5563e37a-802b-4b38-a65f-c41846773aed@github.com>

On Fri, 21 May 2021 05:32:57 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 according to reviewer's feedback.
>
> src/hotspot/share/runtime/globals.hpp line 1995:
> 
>> 1993:           "Memory budget(in bytes) for the buffer of Asynchronous "         \
>> 1994:           "Logging (-Xlog:async).")                                         \
>> 1995:           range(100*K, 50*M)                                                \
> 
> What is the basis for this range?

The range is a pair of empirical values. 

2*M can guarantee that it won't drop any gclog in trace verbosity. 

100k is just a fraction of memory and 50M is a wild guess. I have never seen any log dropped with 50m budget in any program. 

If we don't set a up-bound, the user can tweak it and the buffer will be effectively unbounded. That will change our the design and may cause undefined behaviors. eg. allocation may fail,  the semaphore _sem may overflow etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 09:10:27 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 09:10:27 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Update according to reviewers' feedback (Part-2).

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/2381ba19..cad42d79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=17-18

  Stats: 67 lines in 5 files changed: 29 ins; 10 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Sat May 22 09:10:27 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 22 May 2021 09:10:27 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v17]
In-Reply-To: <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <PtgSKOkn8f9qeGEZH70WK6VHdgPloMicrhsOjpEvIK8=.451dbd52-7300-45f8-a174-5881aba913e2@github.com>
 <aew8eiWATL1Xw_rJ15qNzyyi5vszg3tiP_3hCShztHY=.40f04d19-3889-44f7-8ffe-4c3a7b442b0e@github.com>
Message-ID: <ZHTCECeXUclOBGlHDhqnro3huKGxpAIB-_wKuXVnZk4=.17cd9360-7bef-4c3c-920d-7dac4f169a98@github.com>

On Fri, 21 May 2021 05:55: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 according to reviewer's feedback.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 115:
> 
>> 113: class AsyncLogWriter: public NonJavaThread {
>> 114:   static AsyncLogWriter* _instance;
>> 115:   static Semaphore _sem;
> 
> What is this semaphore for? A comment and/or a more meaningful name would be good.

I added some comments here and _sem.wait().

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From ayang at openjdk.java.net  Sat May 22 21:47:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sat, 22 May 2021 21:47:14 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
Message-ID: <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>

On Sat, 22 May 2021 09:10:27 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update according to reviewers' feedback (Part-2).

src/hotspot/share/logging/logAsyncWriter.cpp line 35:

> 33: class AsyncLogLocker : public StackObj {
> 34:  private:
> 35:   debug_only(static intx _locking_thread_id;)

It's unclear to me what this variable is for.

src/hotspot/share/logging/logAsyncWriter.cpp line 129:

> 127:   AsyncLogBuffer logs;
> 128:   { // critical region
> 129:     AsyncLogLocker ml;

For consistency, I suggest `lock` as the name.

src/hotspot/share/logging/logAsyncWriter.cpp line 134:

> 132:     _buffer.pop_all(&logs);
> 133:     // append meta-messages of dropped counters
> 134:     _stats.iterate(&dropped_counters_iter);

Any particular reason why the iterator is *not* declared right above its usage? IOW, why not


_buffer.pop_all(&logs);
AsyncLogMapIterator dropped_counters_iter(logs);
_stats.iterate(&dropped_counters_iter);

src/hotspot/share/logging/logAsyncWriter.cpp line 152:

> 150:   _state = ThreadState::Running;
> 151: 
> 152:   while (_state == ThreadState::Running) {

`_state` would never change from now on, right? If so, `while (true)` should suffice, IMO.

src/hotspot/share/logging/logAsyncWriter.hpp line 137:

> 135: class AsyncLogWriter : public NonJavaThread {
> 136:   static AsyncLogWriter* _instance;
> 137:   // _sem is a semaphore whose value denotes how many messages have been enqueued.

"how many messages have been enqueued" seems to suggest it's a monotonically growing number as new message are enqueued. In fact, this number will decrease as `_buffer` is flushed. Maybe "_sem denotes the number of messages in _buffer` and moving the two together?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
Message-ID: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From boris.ulasevich at bell-sw.com  Sun May 23 20:37:30 2021
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Sun, 23 May 2021 23:37:30 +0300
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
 <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
 <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>
Message-ID: <c5427513-d770-4cad-182e-0c29f66e62b7@bell-sw.com>

Hi Chris,

I checked that the fix works fine and does not bring any regression.
Let me create pull request and sponsor the change.
Here is the fix and reproducer I prepared for review:
https://github.com/openjdk/jdk/compare/master...bulasevich:jdk-8267042-arm32-c1-lock-01
(I think it is worth simplifying the MonitorBugTest)

regards,
Boris

On 20.05.2021 20:13, Chris Cole wrote:
> Hi Boris,
>
> Thanks for looking into this and your support. See comments below.
>
> On Wed, May 19, 2021 at 2:20 AM Boris Ulasevich
> <boris.ulasevich at bell-sw.com> wrote:
>> Hi Chris,
>>
>> I agree that the problem is in C1_MacroAssembler::lock_object.
> I believe that this issue can be fixed by initializing the displaced
> header in either
> C1_MacroAssembler::lock_object/SharedRuntime::generate_native_wrapper
> or in ObjectSynchronizer::quick_enter with changes provided in
> previous email.
>
> I would suggest that where the problem/fix is located depends on what
> the "interface contract" is for initializing the displaced header
> between JIT inlined code and the monitor enter runtime helper. This
> "interface contract" is not documented anywhere so it is defined by
> how things are coded. Before the introduction of
> ObjectSynchronizer::quick_enter(), the runtime helper would always
> initialize the displaced header as appropriate. When
> ObjectSynchronizer::quick_enter() was introduced it changed the
> "interface contract" of the monitor enter runtime helper because there
> is one special case where it no longer always initializes the
> displaced header as appropriate.
>
> I believe that the better design and "interface contract" is to have
> the runtime helper always set the displaced header as appropriate
> (apply change to ObjectSynchronizer::quick_enter and no other changes)
> for the following reasons.
> - Less coupling between JIT code and runtime helper, this coupling
> helped lead to a number of time consuming bugs including 8153107,
> 8077392, and this one.
> - Every place that slow case runtime helper is called, special care is
> required to initialize displaced header, rather then in just one place
> in ObjectSynchronizer::quick_enter.
> - This coupling is also exposed through the
> JVMCIRuntime::monitorenter(JavaThread, oopDesc, BasicLock) interface
> and without updates to ObjectSynchronizer::quick_enter(), anyone (like
> Graal, etc) calling this interface needs to make sure
> BasicLock->_displaced_header is initialized to a non-zero value. My
> guess is that without removing this requirement there may be future
> deadlock issues. Also current users use JVMCIRuntime::monitorenter()
> should be reviewed to ensure that they are initializing
> BasicLock->_displaced_header.
> - JIT inline code and JVMCIRuntime::monitorenter users can possibly be
> smaller and faster, if the JIT inline code determines that the runtime
> helper is needed it can simply call this without first having to
> initialize the displaced header. Also note that JIT code may not have
> the information to know exactly what to set displaced herder to, so I
> will set it to non-zero and the runtime helper may overwrite this
> value with something different based on the additional logic in the
> slow path.
> - Supports fixing -XX:-UseFastLocking develop flag without additional changes
>
> But given that all code except ARM32 C1, assumes an "interface
> contract" that has special case for when displaced header needs to be
> initialized I am not sure that there will be much support for making
> changes that impact all other architectures in the context of the
> ARM32 bug fix (for other architectures there could be a redundant
> setting displaced header to non-zero in
> ObjectSynchronizer::quick_enter()).
>
> Anyway, just my thoughts... I am fine with either location
> (C1_MacroAssembler::lock_object/SharedRuntime::generate_native_wrapper
> or ObjectSynchronizer::quick_enter) to fix this ARM32 bug.
>
>> What I do not like in your fix is
>> - an arbitrary non-zero value is put into disp_hdr address for 'ne' case.
> I somewhat agree that in general the aesthetics of using an arbitrary
> non-zero value isn't ideal. But in this case I believe setting to a
> specific non-zero value would require an additional instruction and I
> don't think this is worth it. Note that this JIT code is inlined to
> every compiled synchronized method and block, so that one extra
> instruction gets multiplied by a large number and increases memory
> usage, especially important for ARM32 with devices generally having
> limited memory.

Sure. And this is how C2 MacroAssembler lock_object implementation
works! I am Ok with the fix.

> The code change for C1_MacroAssembler::lock_object is taken from what
> is done for ARM32 C2 code in C2_MacroAssembler::fast_lock(),
> that is using an arbitrary non-zero value (see
> https://github.com/openjdk/jdk/blob/b7b6acd9b1cafb791827e151712836c4e7140db5/src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp#L122).
> I would suggest that all places should be consistent. Also when other
> architectures call the runtime helper, the displaced header is
> initialize with "unlocked object header" value due to failed attempt
> to do a stack lock and this is somewhat arbitrary (and somewhat
> misleading) (see
> https://github.com/openjdk/jdk/blob/dfe8833f5d9a9ac59857143a86d07f85769b8eae/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L74).
>
> Note that in this context the displaced header is acting like a
> boolean, false = 0 and any other value is true.
>
> So to keep the code small and to be consistent with ARM32 C2, I would
> suggest just using non-zero value. Maybe a better comment in the code
> would be helpful, as follows.
>
> diff --git a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> index 9d5c82dceb9..44ddc3a9da9 100644
> --- a/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> +++ b/src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
> @@ -235,7 +235,11 @@ int C1_MacroAssembler::lock_object(Register hdr,
> Register obj,
>     sub(tmp2, hdr, SP, eq);
>     movs(tmp2, AsmOperand(tmp2, lsr, exact_log2(os::vm_page_size())), eq);
>     // If 'eq' then OK for recursive fast locking: store 0 into a lock record.
> -  str(tmp2, Address(disp_hdr, mark_offset), eq);
> +  // If 'ne' then initialize displaced header with this non-zero value
> +  // to make sure monitor exit is not treated as non-inflated recursive unlock,
> +  // the runtime helper used in slow case doesn't always do this for us
> +  // (see discussion in JDK-8267042)
> +  str(tmp2, Address(disp_hdr, mark_offset));
>     b(fast_lock_done, eq);
>     // else need slow case
>     b(slow_case);
>
>
>> - there is a similar code pattern in
>> SharedRuntime::generate_native_wrapper - should not it be fixed too?
> Good catch, yes this needs to be fixed as well. I would suggest same
> change as for C1_MacroAssembler::lock_object, as follows.
>
> diff --git a/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
> b/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
> index 341cf63c4c9..7de4306aedb 100644
> --- a/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
> +++ b/src/hotspot/cpu/arm/sharedRuntime_arm.cpp
> @@ -1184,7 +1184,11 @@ nmethod*
> SharedRuntime::generate_native_wrapper(MacroAssembler* masm,
>       __ sub(Rtemp, mark, SP, eq);
>       __ movs(Rtemp, AsmOperand(Rtemp, lsr, exact_log2(os::vm_page_size())), eq);
>       // If still 'eq' then recursive locking OK: set displaced header to 0
> -    __ str(Rtemp, Address(disp_hdr,
> BasicLock::displaced_header_offset_in_bytes()), eq);
> +    // If 'ne' then initialize displaced header with this non-zero value
> +    // to make sure monitor exit is not treated as non-inflated
> recursive unlock,
> +    // the runtime helper used in slow case doesn't always do this for us
> +    // (see discussion in JDK-8267042)
> +    __ str(Rtemp, Address(disp_hdr,
> BasicLock::displaced_header_offset_in_bytes()));
>       __ b(lock_done, eq);
>       __ b(slow_lock);
>
>> - the second comment in hdr bits manipulation code is wrong: "// -2-
>> test (hdr - SP) if the low two bits are 0"
> What are you suggesting is wrong? If I read this as a comment about
> the two instructions that follow (sub and movs) then seems to make
> sense to me, but I might be missing something. Also I would think this
> is not really related to this issue and addressed in a separate place
> issue?

The two instructions compare upper bits (not lower two) to ensure the SP 
and
hdr are on the same page. Though, I agree, it is not related to this issue.

 ? // -2- test (hdr - SP) if the low two bits are 0
 ? sub(tmp2, hdr, SP, eq);
 ? movs(tmp2, AsmOperand(tmp2, lsr, exact_log2(os::vm_page_size())), eq);

> Thanks again,
> Chris
>
>> regards,
>> Boris
>>


From kbarrett at openjdk.java.net  Mon May 24 00:17:01 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 May 2021 00:17:01 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
Message-ID: <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com>

On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up assembler_<cpu>.inline.hpp

Code changes look fine.  This needs an update to the style guide too.

-------------

Changes requested by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From xliu at openjdk.java.net  Mon May 24 02:04:58 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 02:04:58 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
 <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
Message-ID: <yxrZ_BXQ38OvIZALUxf7qRG-HnOnRHAM0t4OshOLCqg=.6428d2f3-adad-4ed0-888b-c568af11f585@github.com>

On Sat, 22 May 2021 21:35:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewers' feedback (Part-2).
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 137:
> 
>> 135: class AsyncLogWriter : public NonJavaThread {
>> 136:   static AsyncLogWriter* _instance;
>> 137:   // _sem is a semaphore whose value denotes how many messages have been enqueued.
> 
> "how many messages have been enqueued" seems to suggest it's a monotonically growing number as new message are enqueued. In fact, this number will decrease as `_buffer` is flushed. Maybe "_sem denotes the number of messages in _buffer` and moving the two together?

The value of _sem denotes the number of messages have been enqueued.  It's actually different from "the number of messages in _buffer".  When  _sem.wait() returns, it just increases one.  however, _buffer.pop_all() pops all messages in queue at once.   The two numbers are not consistent all the time. 

> Maybe "_sem denotes the number of messages in _buffer` and moving the two together?

Could you elaborate this?  thanks?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Mon May 24 03:09:18 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 03:09:18 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
 <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
Message-ID: <KcN1yq0sWqq1vw1RYieLZgakwxD_kweZt-MJafCXp4w=.92016948-b524-45f2-88f7-0d616bba49e8@github.com>

On Sat, 22 May 2021 21:27:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewers' feedback (Part-2).
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 134:
> 
>> 132:     _buffer.pop_all(&logs);
>> 133:     // append meta-messages of dropped counters
>> 134:     _stats.iterate(&dropped_counters_iter);
> 
> Any particular reason why the iterator is *not* declared right above its usage? IOW, why not
> 
> 
> _buffer.pop_all(&logs);
> AsyncLogMapIterator dropped_counters_iter(logs);
> _stats.iterate(&dropped_counters_iter);

yes, it works.  I will update it. 
I unconsciously wrote code in C style. ie. declarations come first, code snippet follows.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Mon May 24 03:34:53 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 03:34:53 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
 <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
Message-ID: <zM2gBBl7T_DhzNWVEQ_TYgrU7bm3D3zbMHCUy9F1jgM=.fd10aa8b-3b2d-4d63-822f-f33adeb524aa@github.com>

On Sat, 22 May 2021 21:08:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update according to reviewers' feedback (Part-2).
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 35:
> 
>> 33: class AsyncLogLocker : public StackObj {
>> 34:  private:
>> 35:   debug_only(static intx _locking_thread_id;)
> 
> It's unclear to me what this variable is for.

thanks. I will delete it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Mon May 24 04:12:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 04:12:54 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  flush() waits until all pending logging IO operations are done.
  
  This patch support all gtests in async mode.
  make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/cad42d79..9800a8cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=18-19

  Stats: 24 lines in 6 files changed: 15 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Mon May 24 04:29:15 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 04:29:15 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
Message-ID: <dP37C8OOeQy59_4ecjfdFT0-7mrTbk_SZigR3xe3quQ=.5f0cb40a-4ef5-48a9-83bd-a04878c904f9@github.com>

On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flush() waits until all pending logging IO operations are done.
>   
>   This patch support all gtests in async mode.
>   make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'

> > _Mailing list message from [Liu, Xin](mailto:xxinliu at amazon.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> > hi, David,
> > I am aware of this issue. There are a few gtest testcases can't run in
> > async logging mode. The rootcause is testing code assumes logging is
> > synchronous.
> > eg. this testcase opens and reads 'TestLogFileName' right after
> > log_trace(). This is perfectly fine in sequential execution. It's unsafe
> > and TestLogFileName may haven't been written yet. fopen could fail(no
> > error check in current testing) and then fread yields NULL pointer for
> > strcmp.
> > TEST_VM_F(LogTest, prefix) {
> > set_log_config(TestLogFileName, "logging+test=trace");
> > log_trace(logging, test)(LOG_LINE_STR);
> > EXPECT_TRUE(file_contains_substring(TestLogFileName, LOG_PREFIX_STR
> > LOG_LINE_STR));
> > }
> > It's also not MT-safe to do concurrent fread() (gtest EXPECT/ASSERT)
> > while fwrite is onging(AsyncLog Thread). Random execution may happen if
> > FILE has been corrupted.
> > I manage to fix those hard crashes in gtests. It would up a non-trivial
> > patch, and it just fixed hard crashes. I reckon I give up running gtest
> > in async mode and provide an isolated and a clean room to test it.
> 
> Hi Xin,
> 
> I agree that these UL tests are annoying because they modify global VM state - resetting global UL options which ideally should just be set at VM startup and then never touched. gtest should not do this.
> 
> I struggled with the same thing with NMT in this upcoming PR: #2921.
> 
> As I wrote before, in my view, it should be possible to execute the gtest suite with any form of UL options - or VM options in general - and the gtests should at most _react_ on those options, never change them. In the case of UL, maybe conditionally execute or skip some tests if UL is on or off.
> 
> In other words, I should be able to run `gtestLauncher -jdk:... -Xlog:os` and the gtests should run through successfully with these flags. And then, as a complimentary step, we execute the gtests (or selected parts of them with --gtest_filter) with selected, non-default, VM options. E.g. with UL turned on. I know you do this already for some of the Async tests, and maybe thats the way to go for all UL gtests. We do this also for Metaspace- and large-page-tests. And I will modify the NMT gtests to not modify NMT state anymore:https://github.com/openjdk/jdk/pull/2921/files#diff-c1004f2502ccc5f5340e7752264c7e0274f6a5fe4da0554d89d3bc8209801199 )
> 
> Moreover, things like "log to a file and scan for expected output" are really better suited for jtreg tests anyway, which spawn a child VM with options and scan the log output. Doing this in gtests seems wrong. Jtreg gives more fine-grained control, I can `-retain` the output files, I can execute them in parallel, Problemlist them, etc. I don't have to execute test logic like reading the log output file _inside_ the logging VM.
> 
> So maybe (future RFE?) we need to move part or all of the UL tests out of the gtest suite and make them jtreg tests.
> 
> Cheers, Thomas



> > _Mailing list message from [Liu, Xin](mailto:xxinliu at amazon.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> > hi, David,
> > I am aware of this issue. There are a few gtest testcases can't run in
> > async logging mode. The rootcause is testing code assumes logging is
> > synchronous.
> > eg. this testcase opens and reads 'TestLogFileName' right after
> > log_trace(). This is perfectly fine in sequential execution. It's unsafe
> > and TestLogFileName may haven't been written yet. fopen could fail(no
> > error check in current testing) and then fread yields NULL pointer for
> > strcmp.
> > TEST_VM_F(LogTest, prefix) {
> > set_log_config(TestLogFileName, "logging+test=trace");
> > log_trace(logging, test)(LOG_LINE_STR);
> > EXPECT_TRUE(file_contains_substring(TestLogFileName, LOG_PREFIX_STR
> > LOG_LINE_STR));
> > }
> > It's also not MT-safe to do concurrent fread() (gtest EXPECT/ASSERT)
> > while fwrite is onging(AsyncLog Thread). Random execution may happen if
> > FILE has been corrupted.
> > I manage to fix those hard crashes in gtests. It would up a non-trivial
> > patch, and it just fixed hard crashes. I reckon I give up running gtest
> > in async mode and provide an isolated and a clean room to test it.
> 
> Hi Xin,
> 
> I agree that these UL tests are annoying because they modify global VM state - resetting global UL options which ideally should just be set at VM startup and then never touched. gtest should not do this.
> 
> I struggled with the same thing with NMT in this upcoming PR: #2921.
> 
> As I wrote before, in my view, it should be possible to execute the gtest suite with any form of UL options - or VM options in general - and the gtests should at most _react_ on those options, never change them. In the case of UL, maybe conditionally execute or skip some tests if UL is on or off.
> 
> In other words, I should be able to run `gtestLauncher -jdk:... -Xlog:os` and the gtests should run through successfully with these flags. And then, as a complimentary step, we execute the gtests (or selected parts of them with --gtest_filter) with selected, non-default, VM options. E.g. with UL turned on. I know you do this already for some of the Async tests, and maybe thats the way to go for all UL gtests. We do this also for Metaspace- and large-page-tests. And I will modify the NMT gtests to not modify NMT state anymore:https://github.com/openjdk/jdk/pull/2921/files#diff-c1004f2502ccc5f5340e7752264c7e0274f6a5fe4da0554d89d3bc8209801199 )
> 
> Moreover, things like "log to a file and scan for expected output" are really better suited for jtreg tests anyway, which spawn a child VM with options and scan the log output. Doing this in gtests seems wrong. Jtreg gives more fine-grained control, I can `-retain` the output files, I can execute them in parallel, Problemlist them, etc. I don't have to execute test logic like reading the log output file _inside_ the logging VM.
> 
> So maybe (future RFE?) we need to move part or all of the UL tests out of the gtest suite and make them jtreg tests.
> 
> Cheers, Thomas

Hi, Thomas

Thanks for the advice. I agree.  OpenJDK have invested so much on those unified logging tests. It's wasteful if I skip them in async mode. I manage to resolve the race conditions. 

To support it, I strengthen "AsyncLogWriter::flush()".  Now it not only flushes pending messages out of buffer, it guarantees all logs messages are seen by external.  one lock  _io_sem is introduced to consolidate that. 

By inserting AsyncLogWriter::flush() in some places of unified logging tests, I can pass all gtests in async mode. I verified it in different builds.  flush() is no-op if async log is not established.

Amazingly, I discovered a very subtle bug also. The following call can also turn off all log outputs but it will bypass `LogConfiguration::disable_outputs()`. Fixed. 


LogConfiguration::parse_log_arguments(filename, "all=off", "", "", &stream);



@dholmes-ora , 
Could you verify that with TEST_OPTS='VM_OPTIONS=-Xlog:async'?
I also verified on Windows 10(WSL1). It works as expected.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From david.holmes at oracle.com  Mon May 24 05:34:59 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 24 May 2021 15:34:59 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <yxrZ_BXQ38OvIZALUxf7qRG-HnOnRHAM0t4OshOLCqg=.6428d2f3-adad-4ed0-888b-c568af11f585@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
 <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
 <yxrZ_BXQ38OvIZALUxf7qRG-HnOnRHAM0t4OshOLCqg=.6428d2f3-adad-4ed0-888b-c568af11f585@github.com>
Message-ID: <df9662b0-8c32-3321-282b-fa03c67448aa@oracle.com>

On 24/05/2021 12:04 pm, Xin Liu wrote:
> On Sat, 22 May 2021 21:35:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
> 
>>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Update according to reviewers' feedback (Part-2).
>>
>> src/hotspot/share/logging/logAsyncWriter.hpp line 137:
>>
>>> 135: class AsyncLogWriter : public NonJavaThread {
>>> 136:   static AsyncLogWriter* _instance;
>>> 137:   // _sem is a semaphore whose value denotes how many messages have been enqueued.
>>
>> "how many messages have been enqueued" seems to suggest it's a monotonically growing number as new message are enqueued. In fact, this number will decrease as `_buffer` is flushed. Maybe "_sem denotes the number of messages in _buffer` and moving the two together?
> 
> The value of _sem denotes the number of messages have been enqueued.  It's actually different from "the number of messages in _buffer".  When  _sem.wait() returns, it just increases one.  however, _buffer.pop_all() pops all messages in queue at once.   The two numbers are not consistent all the time.

I'm finding the use of the semaphores quite confusing, so I will try to 
summarise things as I see them:

The _lock semaphore is used by AsyncLogLocker to serialize access to the 
intermediate buffer by the threads doing the logging, and to also 
coordinate with the log writer thread clearing the buffer. This is a 
semaphore because a Mutex can't be used when some of the logging takes 
places.

The _sem semaphore is signaled whenever a log item is enqueued, causing 
the log writer thread to unlock from wait() and process the current 
contents of the intermediate buffer. Because we enqueue one at a time 
but dequeue in bulk this means that the log writer thread will spin in:

  while (true) {
   _sem.wait();
   write();
  }

until _sem has a count of zero and so wait() will block. This seems 
inefficient but I'm not sure how to avoid that.

The _io_sem semaphore has just been introduced into 
AsyncLogWriter::write but I can't tell what it is actually trying to 
coordinate. ??

Thanks,
David
-----


>> Maybe "_sem denotes the number of messages in _buffer` and moving the two together?
> 
> Could you elaborate this?  thanks?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From david.holmes at oracle.com  Mon May 24 06:09:52 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 24 May 2021 16:09:52 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <dP37C8OOeQy59_4ecjfdFT0-7mrTbk_SZigR3xe3quQ=.5f0cb40a-4ef5-48a9-83bd-a04878c904f9@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
 <dP37C8OOeQy59_4ecjfdFT0-7mrTbk_SZigR3xe3quQ=.5f0cb40a-4ef5-48a9-83bd-a04878c904f9@github.com>
Message-ID: <0da05c7a-b0cd-4a7a-7322-8c4be0a7a963@oracle.com>

On 24/05/2021 2:29 pm, Xin Liu wrote:
> Hi, Thomas
> 
> Thanks for the advice. I agree.  OpenJDK have invested so much on those unified logging tests. It's wasteful if I skip them in async mode. I manage to resolve the race conditions.
> 
> To support it, I strengthen "AsyncLogWriter::flush()".  Now it not only flushes pending messages out of buffer, it guarantees all logs messages are seen by external.  one lock  _io_sem is introduced to consolidate that.

Sorry I didn't see this before sending my other mail about the role of 
the io_sem.

I don't think this semaphore does what you want/need and it's use during 
a VM abort is likely to be very problematic as we may cause the aborting 
thread to wait for the log writing thread, which may not be above to run 
due to the fact that we are aborting.

IIUC what you are trying to deal with is a case where the log writing 
thread has emptied the buffer and as is busy writing that out, and other 
log messages then get enqueued, but then we abort/terminate and we call 
flush() in the aborting/terminating thread. So now we would have two 
threads trying to write to the log outputs and these different logging 
messages could get interleaved in a confusing way; plus as the aborting 
thread is likely to finish first then it will complete the abort and the 
log writer won't get to finish. But I see two problems here:

First, as noted, making the aborting thread wait() could be very 
problematic for the process of aborting. Perhaps we can do this for a 
normal termination, but not I think for the abort case.

Second, there is still a race as to which thread will get the io_sem 
first and so the output could still be presented in the wrong order. I 
think to solve that you would need to acquire the _io_sem first and hold 
it for the duration of the write() operation. I think this could also be 
a regular Mutex rather than a Semaphore.

> By inserting AsyncLogWriter::flush() in some places of unified logging tests, I can pass all gtests in async mode. I verified it in different builds.  flush() is no-op if async log is not established.
> 
> Amazingly, I discovered a very subtle bug also. The following call can also turn off all log outputs but it will bypass `LogConfiguration::disable_outputs()`. Fixed.
> 
> 
> LogConfiguration::parse_log_arguments(filename, "all=off", "", "", &stream);
> 
> 
> 
> @dholmes-ora ,
> Could you verify that with TEST_OPTS='VM_OPTIONS=-Xlog:async'?

I'm submitting it to our test system as I did before for tier 1-3 
testing. I'll see if I can also explicitly enable async logging. Though 
I think I'll hold off until the io_sem situation is resolved.

Thanks,
David

> I also verified on Windows 10(WSL1). It works as expected.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From jiefu at openjdk.java.net  Mon May 24 07:39:59 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 24 May 2021 07:39:59 GMT
Subject: RFR: 8267213: cpuinfo_segv is incorrectly triaged as execution
 protection violation on x86_32
In-Reply-To: <-3WeGT4Aeh_4wqf4chZzoAhszgw8IvJavBOKbOVFVOA=.d55a8039-4a63-44d8-bdd6-5585c3cf4787@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <a299142c-6d86-3c70-3420-20a76b2b11d7@oracle.com>
 <-3WeGT4Aeh_4wqf4chZzoAhszgw8IvJavBOKbOVFVOA=.d55a8039-4a63-44d8-bdd6-5585c3cf4787@github.com>
Message-ID: <17DyfuCszkLhKLNW2OuoJjmCnAR4PUOyFrYSdF__WkI=.03331b0a-8acf-45e6-9b92-0d5fb4387b7c@github.com>

On Thu, 20 May 2021 11:24:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > Have you analysed the original crash to check what the actual pc and
> > addr values were?
> 
> Hi @dholmes-ora ,
> 
> After more investigation, I believe this is a signal handling bug.
> 
> In this case, cpuinfo_segv is incorrectly triaged as execution protection violation on Linux/x86_32.
> 
> During VM initialization, cpuinfo_segv [1] will be triggered (by accessing addr=0) on purpose.
> 
> ```
> #0  VM_Version::get_processor_features () at /home/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:630
> #1  0xf720cc21 in VM_Version::initialize () at /home/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:1890
> #2  0xf7206d85 in VM_Version_init () at /home/jdk/src/hotspot/share/runtime/vm_version.cpp:32
> #3  0xf6b72e4f in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:119
> #4  0xf71500c6 in Threads::create_vm (args=0xf621a26c, canTryAgain=0xf621a1d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2854
> #5  0xf6c6b167 in JNI_CreateJavaVM_inner (vm=0xf621a2bc, penv=0xf621a2c0, args=0xf621a26c) at /home/jdk/src/hotspot/share/prims/jni.cpp:3592
> #6  0xf6c6b35c in JNI_CreateJavaVM (vm=0xf621a2bc, penv=0xf621a2c0, args=0xf621a26c) at /home/jdk/src/hotspot/share/prims/jni.cpp:3680
> #7  0xf7fbe61f in InitializeJVM (pvm=0xf621a2bc, penv=0xf621a2c0, ifn=0xf621a300) at /home/jdk/src/java.base/share/native/libjli/java.c:1539
> #8  0xf7fbb283 in JavaMain (_args=0xffffa484) at /home/jdk/src/java.base/share/native/libjli/java.c:415
> #9  0xf7fc1bed in ThreadJavaMain (args=0xffffa484) at /home/jdk/src/java.base/unix/native/libjli/java_md.c:651
> #10 0xf7d983bd in start_thread (arg=0xf621ab40) at pthread_create.c:463
> ```
> 
> The VM can recognizes it as cpuinfo_segv [2] here and assigned the stub.
> But unfortunately, it's re-triaged as execution protection violation on x86_32 when UnguardOnExecutionViolation > 0, which shouldn't happen.
> 
> To avoid this kind of false-positive, one more condition `stub == NULL` is added.
> 
> Note: we don't need to change windows since there is a special signal for this condition [3].
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L466
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L246
> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L2449

May I get reviews for this small fix?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From xliu at openjdk.java.net  Mon May 24 08:27:53 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 08:27:53 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
Message-ID: <wCMIhCUXkMo3dDxn4-3C89ysy2z100VWF547hUQPS6A=.08e8e973-f5ef-428f-b80a-86322cec6570@github.com>

On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flush() waits until all pending logging IO operations are done.
>   
>   This patch support all gtests in async mode.
>   make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'

Your summary about _sem and _lock are correct.  Now let's discuss on _io_sem. introduced in https://github.com/openjdk/jdk/pull/3135/commits/9800a8ccebb4490c9aeca781bc8155149245d308

> IIUC what you are trying to deal with is a case where the log writing
thread has emptied the buffer and as is busy writing that out, and other
log messages then get enqueued, but then we abort/terminate and we call
flush() in the aborting/terminating thread. 

Yes. Another scenario is to hard flush logs so gtest can see them. 

>  So now we would have two threads trying to write to the log outputs and these different logging
messages could get interleaved in a confusing way;
 
interleave? No. _io_sem is a Dijkstra semaphore whose value is 1.  you can imagine that _io_sem denotes the single IO channel in your system. Everybody can do operation P (aka. _io_sem.wait()) but only one can successfully return. Another has to wait because the value of _io_sem is zero. Yes, there's a race condition, but it doesn't matter. winner does the I/O jobs first. It will do operation V (_io_sem.notify()) in its completion and it will wake up the other thread.  flush() first empties the buffer. When it returns, it can guarantee what it dequeued are written. 

Yes, it's possible that first batch of popped messages are written later.  This only happens when a man explicitly "flush" it.  Normally, only log writer thread does the IO. 

> First, as noted, making the aborting thread wait() could be very
problematic for the process of aborting. 

In no content scenario, _io_sem.wait() of aborting thread should return immediately because its value is 1. 
If log write thread is writing, I think it's okay to wait for its 'turn'. That the semantics of "flushing":  make sure all logs are written to the filesystem.  

> Second, there is still a race as to which thread will get the io_sem
first and so the output could still be presented in the wrong order.

Yes, it may flip the order. I think it's still acceptable.  When JVM is aborting,  I manage to dump everything I am holding. 
The only compromise the batch order may be flip and it only happens in extreme condition.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From eosterlund at openjdk.java.net  Mon May 24 08:37:11 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 24 May 2021 08:37:11 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
Message-ID: <uUCAaBd3TtMTQuUvhGwTvKH3xtZC_je0Fg9oFUX1qmg=.0f12157d-a0fc-44c9-95b7-8b0a55a80c73@github.com>

On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up assembler_<cpu>.inline.hpp

Looks great!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From ayang at openjdk.java.net  Mon May 24 09:05:18 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 24 May 2021 09:05:18 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <yxrZ_BXQ38OvIZALUxf7qRG-HnOnRHAM0t4OshOLCqg=.6428d2f3-adad-4ed0-888b-c568af11f585@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
 <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
 <yxrZ_BXQ38OvIZALUxf7qRG-HnOnRHAM0t4OshOLCqg=.6428d2f3-adad-4ed0-888b-c568af11f585@github.com>
Message-ID: <iBv5t0gJbcLwR1JtaEJZbwy92uIVOCJNoAjcCURxzfo=.0689a09c-aec7-44eb-9e24-988e081255d7@github.com>

On Mon, 24 May 2021 02:02:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

> When _sem.wait() returns, it just decreases one. however, _buffer.pop_all() pops all messages in queue at once. The two numbers are not consistent all the time.

Thank you for the explanation. I overlooked the fact that the "consumer" clears out the buffer in bulk.

> Could you elaborate this? thanks?

I mean that "_sem is a semaphore whose value denotes how many messages have been enqueued" is a bit inaccurate, because `write()` will decrement the semaphore value. For example, a producer has enqueued 2 msgs, but `_sem` could be `0`, as `flush` has been called.

However, I don't see a easy way to "fix" this; I am OK with the current comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From ayang at openjdk.java.net  Mon May 24 09:05:20 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 24 May 2021 09:05:20 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
Message-ID: <rBzeRVpywoBlTU1HuK9bIWrbulXK776ZQQ_ba9J3UVQ=.6f14eca5-515b-4ba3-a779-47247fb9d34a@github.com>

On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flush() waits until all pending logging IO operations are done.
>   
>   This patch support all gtests in async mode.
>   make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'

src/hotspot/share/logging/logAsyncWriter.hpp line 147:

> 145:     Initialized,
> 146:     Running,
> 147:     Terminated,

These two states can be removed now, right? If so, maybe having a binary state (`volatile bool _initialized`) is enough and easier to follow.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From dholmes at openjdk.java.net  Mon May 24 09:34:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 May 2021 09:34:01 GMT
Subject: RFR: 8267213: cpuinfo_segv is incorrectly triaged as execution
 protection violation on x86_32 [v4]
In-Reply-To: <5HjBGAoSyOYzHJcb5PB0KdE-NqSPrQt4pDRHYGyrtDE=.1c967ae4-38c3-4d64-8577-ac08098c9e2c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <5HjBGAoSyOYzHJcb5PB0KdE-NqSPrQt4pDRHYGyrtDE=.1c967ae4-38c3-4d64-8577-ac08098c9e2c@github.com>
Message-ID: <rEIduOaqSzBSaXnaJ2MF2ltjfWOkruw4fY6BiT1gBJI=.9ddbcc75-fc01-4029-a8b6-b8575d7522ce@github.com>

On Thu, 20 May 2021 09:21:56 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> This is a follow-up of JDK-8260046.
>> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
>> Let's fix it
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cpuinfo_segv should not be triaged as execution protection violation

Sorry for the delay.

The revised analysis and fix seems reasonable.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4044

From david.holmes at oracle.com  Mon May 24 09:38:34 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 24 May 2021 19:38:34 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <wCMIhCUXkMo3dDxn4-3C89ysy2z100VWF547hUQPS6A=.08e8e973-f5ef-428f-b80a-86322cec6570@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
 <wCMIhCUXkMo3dDxn4-3C89ysy2z100VWF547hUQPS6A=.08e8e973-f5ef-428f-b80a-86322cec6570@github.com>
Message-ID: <9c60282c-6567-2578-5b47-45434511a583@oracle.com>

On 24/05/2021 6:27 pm, Xin Liu wrote:
> On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>> underlying files periodically.
>>
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    flush() waits until all pending logging IO operations are done.
>>    
>>    This patch support all gtests in async mode.
>>    make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'
> 
> Your summary about _sem and _lock are correct.  Now let's discuss on _io_sem. introduced in https://github.com/openjdk/jdk/pull/3135/commits/9800a8ccebb4490c9aeca781bc8155149245d308
> 
>> IIUC what you are trying to deal with is a case where the log writing
> thread has emptied the buffer and as is busy writing that out, and other
> log messages then get enqueued, but then we abort/terminate and we call
> flush() in the aborting/terminating thread.
> 
> Yes. Another scenario is to hard flush logs so gtest can see them.
> 
>>   So now we would have two threads trying to write to the log outputs and these different logging
> messages could get interleaved in a confusing way;
>   
> interleave? No. _io_sem is a Dijkstra semaphore whose value is 1.  you can imagine that _io_sem denotes the single IO channel in your system. Everybody can do operation P (aka. _io_sem.wait()) but only one can successfully return. Another has to wait because the value of _io_sem is zero. Yes, there's a race condition, but it doesn't matter. winner does the I/O jobs first. It will do operation V (_io_sem.notify()) in its completion and it will wake up the other thread.  flush() first empties the buffer. When it returns, it can guarantee what it dequeued are written.
> 
> Yes, it's possible that first batch of popped messages are written later.  This only happens when a man explicitly "flush" it.  Normally, only log writer thread does the IO.

That is what I meant by interleaved. The two blocks of logging 
statements can be output in the wrong order.

>> First, as noted, making the aborting thread wait() could be very
> problematic for the process of aborting.
> 
> In no content scenario, _io_sem.wait() of aborting thread should return immediately because its value is 1.
> If log write thread is writing, I think it's okay to wait for its 'turn'. That the semantics of "flushing":  make sure all logs are written to the filesystem.

I don't agree. Making the aborting thread wait could be a problem. 
Remember while an abort is in progress all other threads continue to run 
and so by delaying the actual abort we can cause additional secondary 
failures to occur. That doesn't seem like a good trade-off to me wrt. 
issuing some additional logging. If the fault leads to the log writer 
thread also faulting then the abort will hang.

>> Second, there is still a race as to which thread will get the io_sem
> first and so the output could still be presented in the wrong order.
> 
> Yes, it may flip the order. I think it's still acceptable.  When JVM is aborting,  I manage to dump everything I am holding.
> The only compromise the batch order may be flip and it only happens in extreme condition.

Do the log messages already contain the appropriate timestamps from the 
original log call, or is that added when the log message is actually 
output to the destination? If the timestamps are already present and the 
log will just present two blocks out-of-order then that is not too bad. 
Hopefully the developer will spot them. But if the log appeared to show 
things happening in the wrong chronological order then that would be a 
big problem IMO.

Happy to hear other opinions.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From jiefu at openjdk.java.net  Mon May 24 09:38:05 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 24 May 2021 09:38:05 GMT
Subject: RFR: 8267213: cpuinfo_segv is incorrectly triaged as execution
 protection violation on x86_32 [v4]
In-Reply-To: <rEIduOaqSzBSaXnaJ2MF2ltjfWOkruw4fY6BiT1gBJI=.9ddbcc75-fc01-4029-a8b6-b8575d7522ce@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
 <5HjBGAoSyOYzHJcb5PB0KdE-NqSPrQt4pDRHYGyrtDE=.1c967ae4-38c3-4d64-8577-ac08098c9e2c@github.com>
 <rEIduOaqSzBSaXnaJ2MF2ltjfWOkruw4fY6BiT1gBJI=.9ddbcc75-fc01-4029-a8b6-b8575d7522ce@github.com>
Message-ID: <__7EhSj42LIOxMN7UPPIUkxT3r-5i3yEvKCfGQ140lY=.9222254d-f466-493c-bc90-a0bd73b7bfaa@github.com>

On Mon, 24 May 2021 09:30:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The revised analysis and fix seems reasonable.

Thanks @dholmes-ora .

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From aph at openjdk.java.net  Mon May 24 11:12:05 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 24 May 2021 11:12:05 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <plnc71_wiI_RoHV--kO1R4jE7JHQ1CwIf6ZmBIcksVs=.637e5398-ce3f-403b-ae34-20f0f3e48123@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
 <plnc71_wiI_RoHV--kO1R4jE7JHQ1CwIf6ZmBIcksVs=.637e5398-ce3f-403b-ae34-20f0f3e48123@github.com>
Message-ID: <fP6YCMFsaKMHyUjcfnfy6gWYrMFWc0MNYva_RiHVYQI=.5d300bda-8edc-4419-a146-24285b457c31@github.com>

On Mon, 17 May 2021 10:50:02 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at mail.openjdk.java.net):_
> 
> On 5/10/21 6:55 AM, Dong Bo wrote:
> 
> > PING? Any comments/suggestions are appreciated.
> > Although this has been reviewed by Ningsheng, we still need help from reviewers here.
> 
> I'm testing this now.

I'm back on this, and I can't see how to run the tests. Paul Sandoz says the perf tests in the `panama-vector` are under a maven project, but which maven project is that? 

You say "When I tested this, the incompatible DecodeBench.java was deleted first since it is all about ShortVector and ByteVector rather than Int64Vector." but I don't know what that means.

Please provide step-by-step instructions that allow anyone to reproduce your results.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3683

From yyang at openjdk.java.net  Mon May 24 11:15:18 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 24 May 2021 11:15:18 GMT
Subject: RFR: 8267239: C1: RangeCheckElimination for % operator if divisor
 is IntConstant [v3]
In-Reply-To: <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
References: <mMQCGgort4QNiXKLv_Yu0ktaimjTDid4HJaKGqeljYw=.6393a65c-7668-4b53-ac51-de1247db876a@github.com>
 <40GCUvFwUxi08a4inydWtopQ9thvWsCOsFz7_-v0QzM=.7255306b-b11d-4fc4-b839-37410bea37a9@github.com>
Message-ID: <owp3pmHXYgGfwrIvb-cuV6gXHXjzu6cDdOMiMuv0IP8=.f6273ac6-f94e-4787-87fc-949f7a4f0cd0@github.com>

On Wed, 19 May 2021 02:42:03 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> % operator follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor(See [LS 15.17.3](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.3)).
>>       
>> So if `y` is a constant integer and not equal to 0, then we can deduce the bound of remainder operation:
>> -  x % -y  ==> [0, y - 1] RCE
>> -  x % y   ==> [0, y - 1] RCE
>> -  -x % y  ==> [-y + 1, 0]
>> -  -x % -y ==> [-y + 1, 0]
>> 
>> Based on above rationale, we can apply RCE for the remainder operations whose dividend is constant integer and >= 0,  e.g.:
>> 
>> 
>> for(int i=0;i<1000;i++){
>>   int top5 = arr[i%5];  // Apply RCE if arr is a loop invariant
>>   ....
>> }
>> 
>> 
>> For more detailed RCE results, please check out the attachment on JBS, it was generated by ArithmeticRemRCE with additional flags -XX:+TraceRangeCheckElimination -XX:+PrintIR.
>> 
>> Testing:
>> - test/hotspot/jtreg/compiler/c1/(slowdebug)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing whitespace; more comment

I think it is not easy/trivial to implement this for C2 since it idealize ModINode to other nodes if divisor is constant integer:

https://github.com/openjdk/jdk/blob/31139108c1ca9d355bd484d692830dfbc8317477/src/hotspot/share/opto/divnode.cpp#L946-L948

https://github.com/openjdk/jdk/blob/31139108c1ca9d355bd484d692830dfbc8317477/src/hotspot/share/opto/divnode.cpp#L166-L192

-------------

PR: https://git.openjdk.java.net/jdk/pull/4083

From stefank at openjdk.java.net  Mon May 24 11:21:24 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 11:21:24 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails
Message-ID: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>

We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

-------------

Commit messages:
 - 8267611: Print more info when pointer_delta assert fails

Changes: https://git.openjdk.java.net/jdk/pull/4163/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4163&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267611
  Stats: 15 lines in 1 file changed: 9 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4163/head:pull/4163

PR: https://git.openjdk.java.net/jdk/pull/4163

From stefank at openjdk.java.net  Mon May 24 12:14:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 12:14:10 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v3]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <aybWpryDEkLIPzdH-5zU4yu2nMcknZyxlyKX2oVHutE=.6232d6e0-13f4-4e3a-b202-491ff54e41ab@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson 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 remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Clean up assembler_<cpu>.inline.hpp
 - 8267464: Circular-dependency resiliant inline headers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/260c1115..4bcd4348

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=01-02

  Stats: 5145 lines in 153 files changed: 2603 ins; 1960 del; 582 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 24 12:14:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 12:14:10 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
 <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com>
Message-ID: <NEjQTx8fQoTPVaeuCiXBa5u-sSrvgLj_TV3jyuNndo0=.2dee63f3-535d-45af-a566-09ee1120e05d@github.com>

On Mon, 24 May 2021 00:14:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up assembler_<cpu>.inline.hpp
>
> Code changes look fine.  This needs an update to the style guide too.

Thanks @kimbarrett and @fisk for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From dongbo at openjdk.java.net  Mon May 24 12:37:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 24 May 2021 12:37:40 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v3]
In-Reply-To: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
Message-ID: <K7wCniFekXgi7BRXHvxdPmOpvgJGvqt03kiTFI7Qik4=.12618f82-c5d3-4d9c-a28c-81e062b1edd6@github.com>

> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
> 
> 
> ## reduce_add2I, before
> mov    w10, v19.s[0]
> mov    w2, v19.s[1]
> add    w10, w0, w10
> add    w10, w10, w2
> ## reduce_add2I, optimized
> addp   v23.2s, v24.2s, v24.2s
> mov    w10, v23.s[0]
> add    w10, w10, w2
> 
> ## reduce_max2I, before
> dup    v16.2d, v23.d[0]
> sminv  s16, v16.4s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> ## reduce_max2I, optimized
> sminp  v16.2s, v23.2s, v23.2s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> 
> 
> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
> 
> 
> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
> # optimized
> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
> # default
> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
> 
> 
> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
> 
> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  trivial fix the format comments in add2I

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3683/files
  - new: https://git.openjdk.java.net/jdk/pull/3683/files/838ccc9c..9d9ee015

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3683/head:pull/3683

PR: https://git.openjdk.java.net/jdk/pull/3683

From dongbo at openjdk.java.net  Mon May 24 12:47:10 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 24 May 2021 12:47:10 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <fP6YCMFsaKMHyUjcfnfy6gWYrMFWc0MNYva_RiHVYQI=.5d300bda-8edc-4419-a146-24285b457c31@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>
 <plnc71_wiI_RoHV--kO1R4jE7JHQ1CwIf6ZmBIcksVs=.637e5398-ce3f-403b-ae34-20f0f3e48123@github.com>
 <fP6YCMFsaKMHyUjcfnfy6gWYrMFWc0MNYva_RiHVYQI=.5d300bda-8edc-4419-a146-24285b457c31@github.com>
Message-ID: <6JP2aGyKfEzQhRpLIaoGxTL_xD_V_65x6A_RB7fTLU4=.006ddd83-43e4-49e1-90ad-3da07daa3960@github.com>

On Mon, 24 May 2021 11:09:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at mail.openjdk.java.net):_
> > On 5/10/21 6:55 AM, Dong Bo wrote:
> > > PING? Any comments/suggestions are appreciated.
> > > Although this has been reviewed by Ningsheng, we still need help from reviewers here.
> > 
> > 
> > I'm testing this now.
> 
> I'm back on this, and I can't see how to run the tests. Paul Sandoz says the perf tests in the `panama-vector` are under a maven project, but which maven project is that?
> 
> You say "When I tested this, the incompatible DecodeBench.java was deleted first since it is all about ShortVector and ByteVector rather than Int64Vector." but I don't know what that means.
> 
> Please provide step-by-step instructions that allow anyone to reproduce your results.

Hi, here are the instructions I used to run the benchmarks:
1. Get the benchmark project in `https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark` (I do this via git):

## git clone https://github.com/openjdk/panama-vector.git
## cd panama-vector
## git checkout -b vectorIntrinsics remotes/origin/vectorIntrinsics

2. Delete incompatible `DecodeBench.java` and compile the project with mainline JDK:

## <set JAVA_HOME to the mainline JDK path>
## cd test/jdk/jdk/incubator/vector/benchmark
## rm src/main/java/benchmark/utf8/DecodeBench.java
## mvn install

3. Run tests:
`## <PATH_TO_TEST_JDK>/bin/java -jar target/vector-benchmarks.jar benchmark.jdk.incubator.vector.Int64Vector.["M"|"ADD"]+[AXIN]*["Masked"]*Lanes -wi 10 -w 1000ms -f 1 -i 10 -r 1000ms`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3683

From dholmes at openjdk.java.net  Mon May 24 12:52:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 May 2021 12:52:41 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <7eS2E7C0tEYfhPTzSeRYNvaKcsbqJ6n44SeO0H8Jvu0=.b3b193e6-0ef4-4b6e-9369-a72fadc16172@github.com>

On Mon, 24 May 2021 11:11:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

LGTM!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4163

From stefank at openjdk.java.net  Mon May 24 12:58:45 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 12:58:45 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Update HotSpot style guide documents

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/4bcd4348..ba9ad1b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=02-03

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
 <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
Message-ID: <lPk0z6baFFN6QyO0FyiIGkTu9xxIRjx0mu2IET_Kl30=.94dea9d7-9715-41c9-8069-91b5b91a6390@github.com>

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <ErcuQXTihK3DvF1qE6VRicIPIaRHK9upkv59SGzW_PA=.b5fbb915-d64e-42bc-b0ff-a02766c6ba9f@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang 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 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From aph at openjdk.java.net  Mon May 24 15:38:23 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 24 May 2021 15:38:23 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v3]
In-Reply-To: <K7wCniFekXgi7BRXHvxdPmOpvgJGvqt03kiTFI7Qik4=.12618f82-c5d3-4d9c-a28c-81e062b1edd6@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <K7wCniFekXgi7BRXHvxdPmOpvgJGvqt03kiTFI7Qik4=.12618f82-c5d3-4d9c-a28c-81e062b1edd6@github.com>
Message-ID: <xmd1W6UrmcbRoYYwWyiSYC9J6HRuO-L0ATBFWpjod5c=.cb8be020-30f1-457d-8e17-73da2450339e@github.com>

On Mon, 24 May 2021 12:37:40 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
>> 
>> 
>> ## reduce_add2I, before
>> mov    w10, v19.s[0]
>> mov    w2, v19.s[1]
>> add    w10, w0, w10
>> add    w10, w10, w2
>> ## reduce_add2I, optimized
>> addp   v23.2s, v24.2s, v24.2s
>> mov    w10, v23.s[0]
>> add    w10, w10, w2
>> 
>> ## reduce_max2I, before
>> dup    v16.2d, v23.d[0]
>> sminv  s16, v16.4s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> ## reduce_max2I, optimized
>> sminp  v16.2s, v23.2s, v23.2s
>> mov    w10, v16.s[0]
>> cmp    w10, w0
>> csel   w10, w10, w0, lt
>> 
>> 
>> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
>> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
>> 
>> 
>> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
>> # optimized
>> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
>> # default
>> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
>> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
>> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
>> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
>> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
>> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
>> 
>> 
>> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
>> 
>> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trivial fix the format comments in add2I

Thanks. Changes look good.

I managed to reproduce your results.


Benchmark                   (size)   Mode  Cnt     Score    Error   Units
Int64Vector.ADDLanes          1024  thrpt    3  4958.747 ? 54.225  ops/ms
Int64Vector.ADDMaskedLanes    1024  thrpt    3  4769.759 ? 12.736  ops/ms
Int64Vector.MAXLanes          1024  thrpt    3  2957.985 ? 88.671  ops/ms
Int64Vector.MAXMaskedLanes    1024  thrpt    3  2921.381 ? 45.408  ops/ms
Int64Vector.MINLanes          1024  thrpt    3  2965.392 ? 25.236  ops/ms
Int64Vector.MINMaskedLanes    1024  thrpt    3  2923.870 ? 53.270  ops/ms

Benchmark                   (size)   Mode  Cnt     Score    Error   Units
Int64Vector.ADDLanes          1024  thrpt    3  3560.100 ? 79.753  ops/ms
Int64Vector.ADDMaskedLanes    1024  thrpt    3  3585.672 ? 57.203  ops/ms
Int64Vector.MAXLanes          1024  thrpt    3  2951.659 ?  9.577  ops/ms
Int64Vector.MAXMaskedLanes    1024  thrpt    3  2876.957 ? 37.005  ops/ms
Int64Vector.MINLanes          1024  thrpt    3  2953.476 ?  3.446  ops/ms
Int64Vector.MINMaskedLanes    1024  thrpt    3  2878.942 ? 50.281  ops/ms

-------------

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3683

From iwalulya at openjdk.java.net  Mon May 24 16:29:06 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 24 May 2021 16:29:06 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets
In-Reply-To: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
Message-ID: <63Z1s4HPBy7A4GemTW7I7h2EhRqmUXxMlcJWXrEkUEg=.d164e9a8-1b72-4d11-821d-3bbb9f4326ba@github.com>

On Wed, 19 May 2021 15:23:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
> 
>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
> 
> Over time many problems with performance and in particular memory usage have been observed:
> 
> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
> 
> * there is a substantial memory overhead for managing the data structures: examples are
>     * using separate (hash) tables for the three different types of card containers
>     * there is significant unnecessary preallocation of memory for some of the card set containers
>     * Containers store redundant information
> 
> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
> 
> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
> 
> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
> 
> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
> 
> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
> 
> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
> 
> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
> 
> This initial fully working change can be roughly described with the following properties:
> 
> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
> 
> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
> 
> * there are now four different container types and one meta-container type. These four actual containers are:
>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
> 
> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
> 
> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
> 
> Testing: tier1-8 many times, manual and automated perf testing

src/hotspot/share/gc/g1/g1CardSet.cpp line 357:

> 355: 
> 356: G1CardSet::~G1CardSet() {
> 357:   delete _table;

Suggestion:

  _table.unsafe_reset(InitialLogTableSize);
  delete _table;

src/hotspot/share/gc/g1/g1CardSet.cpp line 452:

> 450:       }
> 451: 
> 452:       CardSetPtr old_value = Atomic::cmpxchg(card_set_addr, cur_card_set, G1CardSet::FullCardSet); // Memory order?

Suggestion:

      CardSetPtr old_value = Atomic::cmpxchg(card_set_addr, cur_card_set, G1CardSet::FullCardSet);

Remove the comment "// Memory order?"

src/hotspot/share/gc/g1/g1CardSet.cpp line 478:

> 476:                                                 uint card_in_region,
> 477:                                                 bool increment_total) {
> 478:   G1CardSetHowl* howling_array = card_set_ptr<G1CardSetHowl>(parent_card_set);

`howling_array` -> `howl`

src/hotspot/share/gc/g1/g1CardSet.cpp line 481:

> 479: 
> 480:   G1AddCardResult add_result;
> 481:   CardSetPtr to_transfer;

Suggestion:

  CardSetPtr to_transfer = nullptr;

src/hotspot/share/gc/g1/g1CardSet.cpp line 488:

> 486: 
> 487:   while (true) {
> 488:     to_transfer = nullptr;

Suggestion:

src/hotspot/share/gc/g1/g1CardSet.cpp line 551:

> 549:   return new_card_set;
> 550: }
> 551: 

Suggestion:

-------------

PR: https://git.openjdk.java.net/jdk/pull/4116

From github.com+28651297+mkartashev at openjdk.java.net  Mon May 24 16:54:17 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Mon, 24 May 2021 16:54:17 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths
Message-ID: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>

Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".

This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 

Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).

The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.

Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.

Results from Linux:

Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
==============================
TEST SUCCESS


Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
* jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode

Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
Test results: passed: 1


Results from Windows 10:

Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
==============================
TEST SUCCESS
Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'


Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
* jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode

Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
Test results: passed: 1

-------------

Commit messages:
 - 8195129: System.load() fails to load from unicode paths

Changes: https://git.openjdk.java.net/jdk/pull/4169/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8195129
  Stats: 294 lines in 7 files changed: 247 ins; 27 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169

PR: https://git.openjdk.java.net/jdk/pull/4169

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From github.com+73799211+gregcawthorne at openjdk.java.net  Mon May 24 18:50:29 2021
From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne)
Date: Mon, 24 May 2021 18:50:29 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
Message-ID: <0JcCtbFlWgnepu7qnSZXuPeupgsPfvvOR20Az_2dJSQ=.a365b573-0b5b-4358-a834-44db59128b0d@github.com>

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne at openjdk.org> wrote:

> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
> 
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux.cpp/hpp.
> This is then used to select the glibcs implementation of
> log, log10, exp at runtime for c1 and c2, iff we have
> glibc 2.29 or greater.
> 
> This will ensure OpenJDK can benefit from future improvements
> to glibc.
> 
> Glibc adheres to the ieee754 standard, unless stated otherwise
> in its spec.
> 
> As there are no stated exceptions in the current glibc spec
> for dlog, dlog10 and dexp, we can assume they currently follow
> ieee754 (which testing confirms). As such, future version of
> glibc are unlikely to lose this compliance with ieee754 in
> future.
> 
> W.r.t performance this patch sees ~15-30% performance improvements for
> log and log10, with ~50-80% performance improvements for exp for the
> common input ranged (which output real numbers). However for the NaN
> and inf output ranges we see a slow down of up to a factor of 2 for
> some functions and architectures.
> 
> Due to this being the uncommon case we assert that this is a
> worthwhile tradeoff.

I have been reading up on the monotonicity paper suggested by Andrew Haley:
[http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf](url)

In order to try and see if I can prove the current glibc implementations of log and exp, for monotonicity.

However, I have come to the conclusion that the paper calculates the relative error threshold for monotonicity for an approximation, and then relies on extra bits of floating-point hardware precision to be guaranteed monotonic. These extra bits of precision are greater than the target representations mantissa bits, which when subsequently rounded at the end (rounding is semi monotonic), leads to a monotonic implementation. No extra bits of floating-point precision are present in AArch64 in-between floating-point operations and so this paper won't help us in this case.

I am currently unsure how the current implementation (from fdlibm I believe) is proven to be monotonic. Perhaps there is a proof I am unaware of. The implementation has obviously stood the test of time at least.

If anyone has an idea of how the existing implementation was proven to be monotonic (if it has been), it could help us to apply it on the Arm optimised routine version (AOR).
What we can do for now is compare the remez approximation used in the current OpenJDK implementation (take log for example):
[https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L49](url)

It states:
" The maximum error of this polynomial approximation is bounded by 2**-58.45"
Which must be the theoretical accuracy, as it would be bounded by the 52 bits of mantissa if run on AArch64. And is insufficient for a proof of monotonicity on its own.

Now if you look AOR for log (where the implementation comes from):
[https://github.com/ARM-software/optimized-routines/blob/master/math/tools/log.sollya](url)
[https://github.com/ARM-software/optimized-routines/blob/master/math/tools/log_abs.sollya](url)
And run them, you will see the abs and relative accuracies of ~2**-63 for log.sollya
And for log_abs.sollya which is used for inputs around 1.0, there is an absolute accuracy of ~2**-65 and a relative error of ~ 2**-56.

So for log the theoretical accuracy is actually higher than the current implementations, apart from when near 1.0 the relative error is slightly worse, however I have confirmed with Szabolcs Nagy at Arm who worked on the implementation, that it is the absolute error here which dictates the effective accuracy, as there is arithmetic afterwards which changes the magnitude.
As for the existing accuracy of the exp the implementation code comments state the maximum theoretical error of the remez approximation is 2**-59.

While running the exp soylla script in AOR:
[https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L238](url)
It shows its remez has a theoretical accuracy of 2**-66.
[https://github.com/ARM-software/optimized-routines/blob/master/math/tools/exp.sollya](url)

Another thing to consider is the reconstruction process of the current fdlibm implementation and glibcs. glibcs exp and log uses a table lookup algorithm in order to allow their polynomial to have a smaller principle domain around 0 and it is then transformed to a larger principle domain, where as fdlibms does use this method.

A description of the table loop up scheme can be found here:
[https://dl.acm.org/doi/pdf/10.1145/63522.214389](url)
And an analysis of the error bounds of table look type approximations of functions can be found here:
[https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=709374](url)

If the remez polynomial of fdlibm isn?t definitively proven to be monotonic, and the glibcs remez polynomials has comparable accuracy. Then it might suffice to attempt to investigate further the effects of the table lookup method implementation; with regards to semi-monotonicity, even if it wouldn?t offer a total proof of the overall implementation.

My initial look at glibcs' exp implementation is that the relationship between the scale and tail variables, along with the table values themselves possibly appearing monotonic themselves, might indicate that it won't break monotonicity. However this would need further investigation and similarly for log, iff this sub sections proof of monotonicity suffices for the overall implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From chris at sageembedded.com  Mon May 24 18:56:12 2021
From: chris at sageembedded.com (Chris Cole)
Date: Mon, 24 May 2021 11:56:12 -0700
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <c5427513-d770-4cad-182e-0c29f66e62b7@bell-sw.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
 <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
 <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>
 <c5427513-d770-4cad-182e-0c29f66e62b7@bell-sw.com>
Message-ID: <CABQ9BCV9WNpGQ2XG_bmi0iEU1YOhB71BHRkWbLv=4mDtgoLhwA@mail.gmail.com>

Hi Boris,

On Sun, May 23, 2021 at 1:38 PM Boris Ulasevich
<boris.ulasevich at bell-sw.com> wrote:
>
> Hi Chris,
>
> I checked that the fix works fine and does not bring any regression.
> Let me create pull request and sponsor the change.
> Here is the fix and reproducer I prepared for review:
> https://github.com/openjdk/jdk/compare/master...bulasevich:jdk-8267042-arm32-c1-lock-01

Sounds great. Looks good to me.

> (I think it is worth simplifying the MonitorBugTest)

Yes, I agree. If you want I could try and simplify this, but won't
have time to work on this until tomorrow.

Thanks,
Chris

From tibordigana at apache.org  Mon May 24 19:26:44 2021
From: tibordigana at apache.org (Tibor Digana)
Date: Mon, 24 May 2021 21:26:44 +0200
Subject: Modular LIBJVM.SO library for Docker
Message-ID: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>

Hi,

The size of the library "libjvm.so"o is bigger than Java modules, and
bigger or comparable with the size of the application in the Docker image.

After processing the JDK by the JLINK and shrinking the native library "
libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
big, i.e. 18MB (from the original size 22MB) and the modules have only 12MB.

We have many GC algorithms in the JVM and maybe this is the reason why the
library is bigger than the Java modules and then JLINK does not become much
effective.

Can you please develop a modular JVM library so that I would be able to
select only one algorithm of GC which means that the modules with other GC
algorithms would not appear in my Docker image?

Thx
Tibor

From stefan.karlsson at oracle.com  Mon May 24 19:54:20 2021
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 24 May 2021 21:54:20 +0200
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
Message-ID: <1f4406de-66b7-19f3-01d9-8fa28556da32@oracle.com>

Hi Tibor,

On 2021-05-24 21:26, Tibor Digana wrote:
> Hi,
>
> The size of the library "libjvm.so"o is bigger than Java modules, and
> bigger or comparable with the size of the application in the Docker image.
>
> After processing the JDK by the JLINK and shrinking the native library "
> libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
> big, i.e. 18MB (from the original size 22MB) and the modules have only 12MB.
>
> We have many GC algorithms in the JVM and maybe this is the reason why the
> library is bigger than the Java modules and then JLINK does not become much
> effective.
>
> Can you please develop a modular JVM library so that I would be able to
> select only one algorithm of GC which means that the modules with other GC
> algorithms would not appear in my Docker image?

FWIW, we don't have a modular JVM, but we have support to remove GCs 
from the compilation of libjvm.so. All combinations are not always 
maintained, so you might have to propose patches to fix some of the 
issues you find.

If you run:
bash configure --help

you'll get a list of --enable-jvm-feature-X for the features you can 
compile into the JVM. Use corresponding --disable- flag to remove the 
feature. For example: --disable-jvm-feature-g1gc removes G1 from the 
libjvm.so.

HTH,
StefanK

>
> Thx
> Tibor


From tibordigana at apache.org  Mon May 24 20:29:05 2021
From: tibordigana at apache.org (Tibor Digana)
Date: Mon, 24 May 2021 22:29:05 +0200
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <1f4406de-66b7-19f3-01d9-8fa28556da32@oracle.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
 <1f4406de-66b7-19f3-01d9-8fa28556da32@oracle.com>
Message-ID: <CAKuVzBT0kFWiMPghDhnxvakv7D6b6F1pJ1tZ_k21h03msC6wLg@mail.gmail.com>

Hi Stefan,

.. but I am a user and I like downloading the Openjdk images from docker
hub, not compiling them.
It is not a realistic solution to recompile the sources.
We are looking for a way to minimize the memory footprint in Docker and so
this LIBJVM was found too big.

So the solution would be as follows.

The community may pick up a Docker-friendly GC algorithm (my proposal is
ZGC) and VM settings for Linux, build a second library, i.e. libjvm2.so for
such type of virtualization. And, in the next step the JLINK should add a
new option which would delete libjvm.so and rename the libjvm2.so which
finally enables ZGC by default especially in the virtualization.

I would rather expect this. It would be cool marketing for Java because
Java footprint would be really minimalistic for small embedded devices, and
extremely small Docker images.

Cheers
Tibor







On Mon, May 24, 2021 at 9:54 PM Stefan Karlsson <stefan.karlsson at oracle.com>
wrote:

> Hi Tibor,
>
> On 2021-05-24 21:26, Tibor Digana wrote:
> > Hi,
> >
> > The size of the library "libjvm.so"o is bigger than Java modules, and
> > bigger or comparable with the size of the application in the Docker
> image.
> >
> > After processing the JDK by the JLINK and shrinking the native library "
> > libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
> > big, i.e. 18MB (from the original size 22MB) and the modules have only
> 12MB.
> >
> > We have many GC algorithms in the JVM and maybe this is the reason why
> the
> > library is bigger than the Java modules and then JLINK does not become
> much
> > effective.
> >
> > Can you please develop a modular JVM library so that I would be able to
> > select only one algorithm of GC which means that the modules with other
> GC
> > algorithms would not appear in my Docker image?
>
> FWIW, we don't have a modular JVM, but we have support to remove GCs
> from the compilation of libjvm.so. All combinations are not always
> maintained, so you might have to propose patches to fix some of the
> issues you find.
>
> If you run:
> bash configure --help
>
> you'll get a list of --enable-jvm-feature-X for the features you can
> compile into the JVM. Use corresponding --disable- flag to remove the
> feature. For example: --disable-jvm-feature-g1gc removes G1 from the
> libjvm.so.
>
> HTH,
> StefanK
>
> >
> > Thx
> > Tibor
>
>

From forax at univ-mlv.fr  Mon May 24 21:45:12 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 24 May 2021 23:45:12 +0200 (CEST)
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <CAKuVzBT0kFWiMPghDhnxvakv7D6b6F1pJ1tZ_k21h03msC6wLg@mail.gmail.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
 <1f4406de-66b7-19f3-01d9-8fa28556da32@oracle.com>
 <CAKuVzBT0kFWiMPghDhnxvakv7D6b6F1pJ1tZ_k21h03msC6wLg@mail.gmail.com>
Message-ID: <1655329256.180753.1621892712322.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Tibor Digana" <tibordigana at apache.org>
> ?: "Stefan Karlsson" <stefan.karlsson at oracle.com>
> Cc: "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoy?: Lundi 24 Mai 2021 22:29:05
> Objet: Re: Modular LIBJVM.SO library for Docker

> Hi Stefan,
> 
> .. but I am a user and I like downloading the Openjdk images from docker
> hub, not compiling them.
> It is not a realistic solution to recompile the sources.
> We are looking for a way to minimize the memory footprint in Docker and so
> this LIBJVM was found too big.

Do you know that you can compile the JDK source in a docker container itself with a multi stage build ? [1]

Also if you want a small image and don't care too much about peak performance,
maybe you should take a look at the Graal Native image [2].

> Cheers
> Tibor

regards,
R?mi

[1] https://docs.docker.com/develop/develop-images/multistage-build/
[2] https://www.graalvm.org/reference-manual/native-image/

> 
> 
> 
> 
> 
> 
> 
> On Mon, May 24, 2021 at 9:54 PM Stefan Karlsson <stefan.karlsson at oracle.com>
> wrote:
> 
>> Hi Tibor,
>>
>> On 2021-05-24 21:26, Tibor Digana wrote:
>> > Hi,
>> >
>> > The size of the library "libjvm.so"o is bigger than Java modules, and
>> > bigger or comparable with the size of the application in the Docker
>> image.
>> >
>> > After processing the JDK by the JLINK and shrinking the native library "
>> > libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
>> > big, i.e. 18MB (from the original size 22MB) and the modules have only
>> 12MB.
>> >
>> > We have many GC algorithms in the JVM and maybe this is the reason why
>> the
>> > library is bigger than the Java modules and then JLINK does not become
>> much
>> > effective.
>> >
>> > Can you please develop a modular JVM library so that I would be able to
>> > select only one algorithm of GC which means that the modules with other
>> GC
>> > algorithms would not appear in my Docker image?
>>
>> FWIW, we don't have a modular JVM, but we have support to remove GCs
>> from the compilation of libjvm.so. All combinations are not always
>> maintained, so you might have to propose patches to fix some of the
>> issues you find.
>>
>> If you run:
>> bash configure --help
>>
>> you'll get a list of --enable-jvm-feature-X for the features you can
>> compile into the JVM. Use corresponding --disable- flag to remove the
>> feature. For example: --disable-jvm-feature-g1gc removes G1 from the
>> libjvm.so.
>>
>> HTH,
>> StefanK
>>
>> >
>> > Thx
>> > Tibor
>>

From gziemski at openjdk.java.net  Mon May 24 21:52:48 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 24 May 2021 21:52:48 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
Message-ID: <Lnqxm9SCDsX31hnNtnRmS4nMKJHAefuFYKr2qnXdUcY=.116d7d02-5e1c-4fc9-bfbc-559f0932bb8f@github.com>

On Fri, 21 May 2021 11:07:14 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure pointer is stripped on macos
>   
>   Change-Id: Idcf5f08e87c1e1f5af1dc8f421f8c7efc3d9c4c2
>   CustomizedGitHooks: yes

Please let me know if I understand things correctly:

Apple's **M1** is **arm64e** architecture, so therefore it is **PAC** architecture, however, currently that's only active in **iOS**.

**macOS** does not currently support **PAC**, but we're adding the support to be ready whenever Apple decides to turn it on?

On **PAC** systems the following code:

`ptrauth_strip(&strcpy, ptrauth_key_asib) == &strcpy`

would be false, and on **non PAC** OS , like for now **macOS** it will always be true (since ptrauth_strip is a NOP macro), is that correct?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From xliu at openjdk.java.net  Mon May 24 21:57:59 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 21:57:59 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
Message-ID: <3D13o2Myb1jelX2DtvpeuSv40t7zOnEo4Y81nAOxdM0=.2c5e354e-4229-403b-8d1b-749f2ffb7290@github.com>

On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flush() waits until all pending logging IO operations are done.
>   
>   This patch support all gtests in async mode.
>   make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'

I have a workaround.  this is a biased solution. Who is taking the buffer lock has the priority to obtain the IO channel as well. 

PS: I have to use trywait here to guarantee non-blocking. wait() will make one thread sleep with the buffer lock.  As a result, logsites can't enqueue messages.


void AsyncLogWriter::write() {
...
  AsyncLogBuffer logs;
  bool own_io = false;

  { // critical region
    AsyncLogLocker lock;

    _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();
  }
...


If we only deal with two threads situation, it can prevent the "interleaving" issue.
Whoever fail get the second chance at `_io_sem.wait()`.

> Do the log messages already contain the appropriate timestamps from the original log call, or is that added when the log message is actually output to the destination?

Current implementation can guarantee both of them. 

I have to say that we may over-thinking here. There are 3 situations where we used flush(). they all belong to "two-thread situation". one log writer thread. the other thread invokes `flush()`.

1. termination.
2. abortion
3. gtest. 

It seems that only os::abort() is tricky.  I understand that it will execute with other parallel threads. Actually, I used to run into problem for this one. TEST="gtest:os.page_size_for_region_with_zero_min_pages_vm_assert_test", which trigger segfault on purpose. Now it works fine. 

What do you think about my workaround? 
If you still feel os::abort() is unsafe, how about we just remove flush() from os::abort(). 
I have to say that write() is pretty frequent, and buffer is always empty().

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Mon May 24 22:55:34 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 24 May 2021 22:55:34 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <rBzeRVpywoBlTU1HuK9bIWrbulXK776ZQQ_ba9J3UVQ=.6f14eca5-515b-4ba3-a779-47247fb9d34a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
 <rBzeRVpywoBlTU1HuK9bIWrbulXK776ZQQ_ba9J3UVQ=.6f14eca5-515b-4ba3-a779-47247fb9d34a@github.com>
Message-ID: <__ni1ywIWyPsWGOs1uqzsXtU7JtiPmg-5cRibEfgGdc=.517a9721-d280-4888-af0f-dfb0fe06229d@github.com>

On Mon, 24 May 2021 08:51:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   flush() waits until all pending logging IO operations are done.
>>   
>>   This patch support all gtests in async mode.
>>   make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 147:
> 
>> 145:     Initialized,
>> 146:     Running,
>> 147:     Terminated,
> 
> These two states can be removed now, right? If so, maybe having a binary state (`volatile bool _initialized`) is enough and easier to follow.

make sense.  I will update it along with the trywait() patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From jiefu at openjdk.java.net  Mon May 24 22:58:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 24 May 2021 22:58:06 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <gy8sKM7Gz_rXVKbMOPPKBzqPKKqsxs0jO8F9a-w6poI=.3e047bd4-5d48-4851-99af-70e6e80acfaa@github.com>

On Mon, 24 May 2021 11:11:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

Marked as reviewed by jiefu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4163

From david.holmes at oracle.com  Tue May 25 00:56:44 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 May 2021 10:56:44 +1000
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
Message-ID: <4f6d0b9d-946d-f911-57bf-e3b78d3fc011@oracle.com>

Hi Tibor,

On 25/05/2021 5:26 am, Tibor Digana wrote:
> Hi,
> 
> The size of the library "libjvm.so"o is bigger than Java modules, and
> bigger or comparable with the size of the application in the Docker image.
> 
> After processing the JDK by the JLINK and shrinking the native library "
> libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
> big, i.e. 18MB (from the original size 22MB) and the modules have only 12MB.
> 
> We have many GC algorithms in the JVM and maybe this is the reason why the
> library is bigger than the Java modules and then JLINK does not become much
> effective.

I'm not sure why you think the JVM should be comparable in size to the 
native code used by the core libraries. The JVM is a huge piece of 
native code in comparison to that used by the core libraries.

> Can you please develop a modular JVM library so that I would be able to
> select only one algorithm of GC which means that the modules with other GC
> algorithms would not appear in my Docker image?

This can be built today (modulo some possible issues Stefan mentioned). 
You need to find an OpenJDK provider/distributor who is prepared to take 
on the cost of providing a selection of binaries with different VM 
features enabled.

I've no idea how much size might be saved by stripping out different 
GC's today.

Cheers,
David

> Thx
> Tibor
> 

From yyang at openjdk.java.net  Tue May 25 02:12:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 02:12:03 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
 <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>
Message-ID: <mwujJvG-fQIZ3GZ_YLa2YojPlIN6ZpMYTI2y4n8qfw8=.91ef9d87-a7f8-4fb8-8e80-485b175ea218@github.com>

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better check1-4
>
> Looks like now the test fails in the pre-submit tests?

Hi @veresov, may?I?ask?your?help?to?review?this?patch??Thanks?a?lot.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From dongbo at openjdk.java.net  Tue May 25 02:20:07 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 25 May 2021 02:20:07 GMT
Subject: Integrated: 8264973: AArch64: Optimize vector max/min/add reduction
 of two integers with NEON pairwise instructions
In-Reply-To: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
Message-ID: <koO-G1p6lzlw9vvuTUz56OBrKsjLumMkQwh9t1GkYpw=.facf58c0-b830-4989-a733-1a0af090013e@github.com>

On Mon, 26 Apr 2021 05:50:20 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
> 
> 
> ## reduce_add2I, before
> mov    w10, v19.s[0]
> mov    w2, v19.s[1]
> add    w10, w0, w10
> add    w10, w10, w2
> ## reduce_add2I, optimized
> addp   v23.2s, v24.2s, v24.2s
> mov    w10, v23.s[0]
> add    w10, w10, w2
> 
> ## reduce_max2I, before
> dup    v16.2d, v23.d[0]
> sminv  s16, v16.4s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> ## reduce_max2I, optimized
> sminp  v16.2s, v23.2s, v23.2s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> 
> 
> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
> 
> 
> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
> # optimized
> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
> # default
> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
> 
> 
> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
> 
> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java

This pull request has now been integrated.

Changeset: 123cdd1f
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/123cdd1fbd4fa02177c06afb67a09aee21d0a482
Stats:     294 lines in 5 files changed: 23 ins; 12 del; 259 mod

8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions

Reviewed-by: njian, aph

-------------

PR: https://git.openjdk.java.net/jdk/pull/3683

From iveresov at openjdk.java.net  Tue May 25 02:28:01 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 25 May 2021 02:28:01 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v9]
In-Reply-To: <BtR2gR2JzdslWm0v3dpLqKoJ3HPGcpGLtaF2iE70Igw=.84418518-d27c-47b2-a148-f764aefdd3eb@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <BtR2gR2JzdslWm0v3dpLqKoJ3HPGcpGLtaF2iE70Igw=.84418518-d27c-47b2-a148-f764aefdd3eb@github.com>
Message-ID: <ZAolCXQrvGwvnBbpiFxftRJ-mRvf6kUB2_QndI-exzM=.e20d8932-3245-4d02-b7c2-9cce8b74f82d@github.com>

On Sat, 8 May 2021 03:00:14 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   x86_32 fails

Marked as reviewed by iveresov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Tue May 25 02:48:06 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 02:48:06 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
 <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>
Message-ID: <YvaM1tuy_lTUxAAxs_MvjPY-HtiME1G-7xMEdqZy7gY=.2dcf8dcb-6b7b-4b74-947c-3e39a6df09ec@github.com>

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better check1-4
>
> Looks like now the test fails in the pre-submit tests?

Thank you @veresov! 

I'm glad to have more comments from hotspot-compiler group.

Later, I'd like to integrate it if there are no more comments/objections.

Thanks!
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Tue May 25 03:14:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 03:14:30 GMT
Subject: RFR: 8267657: Add missing PrintC1Statistics before incrementing
 counters
Message-ID: <3y_kn9nUEynQogBERppD9dKS5rx7An1LH01suSXUJho=.e3ffc36b-fa8a-45a5-b957-91ef009148d1@github.com>

Trivial change to add missing PrintC1Statistics before incrementing counters.

-------------

Commit messages:
 - trivial

Changes: https://git.openjdk.java.net/jdk/pull/4178/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4178&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267657
  Stats: 96 lines in 7 files changed: 61 ins; 6 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4178/head:pull/4178

PR: https://git.openjdk.java.net/jdk/pull/4178

From david.holmes at oracle.com  Tue May 25 05:23:29 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 May 2021 15:23:29 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <3D13o2Myb1jelX2DtvpeuSv40t7zOnEo4Y81nAOxdM0=.2c5e354e-4229-403b-8d1b-749f2ffb7290@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
 <3D13o2Myb1jelX2DtvpeuSv40t7zOnEo4Y81nAOxdM0=.2c5e354e-4229-403b-8d1b-749f2ffb7290@github.com>
Message-ID: <f64825ea-df1e-5e25-b3c1-bfdd4562f5f8@oracle.com>

Hi Xin,

On 25/05/2021 7:57 am, Xin Liu wrote:
> On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>> underlying files periodically.
>>
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    flush() waits until all pending logging IO operations are done.
>>    
>>    This patch support all gtests in async mode.
>>    make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'
> 
> I have a workaround.  this is a biased solution. Who is taking the buffer lock has the priority to obtain the IO channel as well.
> 
> PS: I have to use trywait here to guarantee non-blocking. wait() will make one thread sleep with the buffer lock.  As a result, logsites can't enqueue messages.
> 
> 
> void AsyncLogWriter::write() {
> ...
>    AsyncLogBuffer logs;
>    bool own_io = false;
> 
>    { // critical region
>      AsyncLogLocker lock;
> 
>      _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();
>    }
> ...
> 
> 
> If we only deal with two threads situation, it can prevent the "interleaving" issue.
> Whoever fail get the second chance at `_io_sem.wait()`.

Yes this seems quite reasonable for dealing with that part of the problem.

>> Do the log messages already contain the appropriate timestamps from the original log call, or is that added when the log message is actually output to the destination?
> 
> Current implementation can guarantee both of them.

I'm not sure what that means as I only expect there to be one timestamp. 
I'm just not sure if it is recording the time at which the log call was 
made, or the time (later) when that log record was actually written out?

> I have to say that we may over-thinking here. 

Possibly. :) But best to flesh this out now rather than trying to chase 
down issues later that may not become apparent for a while.

> There are 3 situations where we used flush(). they all belong to "two-thread situation". one log writer thread. the other thread invokes `flush()`.
> 
> 1. termination.
> 2. abortion
> 3. gtest.
> 
> It seems that only os::abort() is tricky.  I understand that it will execute with other parallel threads. Actually, I used to run into problem for this one. TEST="gtest:os.page_size_for_region_with_zero_min_pages_vm_assert_test", which trigger segfault on purpose. Now it works fine.
> 
> What do you think about my workaround?

I like it.

> If you still feel os::abort() is unsafe, how about we just remove flush() from os::abort().

I think doing a hard wait() when aborting is risky - but again I'd like 
to hear other opinions on that (paging @stuefe!).

Not flushing on abort is one option. If we can pass through to write() 
the fact that we are aborting then another option would be to simply 
skip the write if the try_wait fails.

> I have to say that write() is pretty frequent, and buffer is always empty().

Using what applications and logging settings?

If the buffer is nearly always empty and so it is very unlikely that the 
final flush will have much, if anything to do, then arguably you don't 
need the io_sem complexity, as at worst you will potentially see a 
handful of log messages out-of-order.

PS. Testing tiers 1-3 on our CI went okay.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From xliu at openjdk.java.net  Tue May 25 05:23:56 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 25 May 2021 05:23:56 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v21]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with two additional commits since the last revision:

 - Remove AsyncLogWriter::flush() from os::shutdown().
   
   When jvm aborts, it won't invoke AsyncLogWriter::flush() and guarantee
   not to hinder the aborting process.
   
   Run all unified logging tests in async mode.
 - Biased to the thread which is taking buffer lock.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/9800a8cc..2ffc33fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=19-20

  Stats: 32 lines in 5 files changed: 7 ins; 15 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Tue May 25 05:51:13 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 25 May 2021 05:51:13 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
In-Reply-To: <f64825ea-df1e-5e25-b3c1-bfdd4562f5f8@oracle.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <f64825ea-df1e-5e25-b3c1-bfdd4562f5f8@oracle.com>
Message-ID: <GaW0iUzRXRQkYIGC5idBRdt1cd6jzvnLxmGR3L_aivI=.5361547a-b3ea-4752-81b1-0ed44191a6d7@github.com>

On Tue, 25 May 2021 05:25:40 GMT, David Holmes <david.holmes at oracle.com> wrote:

> I'm not sure what that means as I only expect there to be one timestamp.
I'm just not sure if it is recording the time at which the log call was
made, or the time (later) when that log record was actually written out?

Sorry. I updated the answer today. Let me elaborate it. Current implementation uses the original timestamps, which are accurate. When I create AsyncLogMessage instance, I copy _decorations. 
@tstuefe recently compressed that class. 

> Using what applications and logging settings?

My observation is based on my integration test. Current semaphore-based synchronization can catch up the pace of gclog=trace.
https://github.com/openjdk/jdk/pull/3135#issuecomment-827135465

> If the buffer is nearly always empty and so it is very unlikely that the
final flush will have much, if anything to do, then arguably you don't
need the io_sem complexity.

_io_sem is introduced to pass unified logging test in async mode. I just enable them.
https://github.com/openjdk/jdk/pull/3135/commits/2ffc33feaf5757bc5744440278e7750a9f2b81bf

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From stefank at openjdk.java.net  Tue May 25 06:19:04 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 25 May 2021 06:19:04 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <OLK2JgpBAEQS6rbkDvLkAOwBHtkuqgQZuxF3bBt6iIA=.5c3f4eb5-0e02-47a8-8301-ae679c925eea@github.com>

On Mon, 24 May 2021 11:11:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4163

From david.holmes at oracle.com  Tue May 25 06:47:48 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 May 2021 16:47:48 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
In-Reply-To: <GaW0iUzRXRQkYIGC5idBRdt1cd6jzvnLxmGR3L_aivI=.5361547a-b3ea-4752-81b1-0ed44191a6d7@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <f64825ea-df1e-5e25-b3c1-bfdd4562f5f8@oracle.com>
 <GaW0iUzRXRQkYIGC5idBRdt1cd6jzvnLxmGR3L_aivI=.5361547a-b3ea-4752-81b1-0ed44191a6d7@github.com>
Message-ID: <fc63fad7-b267-0271-a484-d242ff2b6711@oracle.com>

On 25/05/2021 3:51 pm, Xin Liu wrote:
> On Tue, 25 May 2021 05:25:40 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> I'm not sure what that means as I only expect there to be one timestamp.
> I'm just not sure if it is recording the time at which the log call was
> made, or the time (later) when that log record was actually written out?
> 
> Sorry. I updated the answer today. Let me elaborate it. Current implementation uses the original timestamps, which are accurate. When I create AsyncLogMessage instance, I copy _decorations.
> @tstuefe recently compressed that class.
> 
>> Using what applications and logging settings?
> 
> My observation is based on my integration test. Current semaphore-based synchronization can catch up the pace of gclog=trace.
> https://github.com/openjdk/jdk/pull/3135#issuecomment-827135465
> 
>> If the buffer is nearly always empty and so it is very unlikely that the
> final flush will have much, if anything to do, then arguably you don't
> need the io_sem complexity.
> 
> _io_sem is introduced to pass unified logging test in async mode. I just enable them.
> https://github.com/openjdk/jdk/pull/3135/commits/2ffc33feaf5757bc5744440278e7750a9f2b81bf

It isn't at all clear why it was necessary to introduce the io_sem just 
so some gtest will pass. Why did these tests fail?

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From david.holmes at oracle.com  Tue May 25 06:52:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 May 2021 16:52:56 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v21]
In-Reply-To: <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
Message-ID: <14ecd7ba-61e0-355b-806c-8fd9edd8d7c4@oracle.com>

On 25/05/2021 3:23 pm, Xin Liu wrote:
>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
> 
> Xin Liu has updated the pull request incrementally with two additional commits since the last revision:
> 
>   - Remove AsyncLogWriter::flush() from os::shutdown().

You should have waited till there was further discussion on this as 
there needs to be a consensus on what is needed here.

David
-----

>     When jvm aborts, it won't invoke AsyncLogWriter::flush() and guarantee
>     not to hinder the aborting process.
>     
>     Run all unified logging tests in async mode.
>   - Biased to the thread which is taking buffer lock.
> 
> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/3135/files
>    - new: https://git.openjdk.java.net/jdk/pull/3135/files/9800a8cc..2ffc33fe
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=20
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=19-20
> 
>    Stats: 32 lines in 5 files changed: 7 ins; 15 del; 10 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From xliu at openjdk.java.net  Tue May 25 07:30:23 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 25 May 2021 07:30:23 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
In-Reply-To: <fc63fad7-b267-0271-a484-d242ff2b6711@oracle.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <fc63fad7-b267-0271-a484-d242ff2b6711@oracle.com>
Message-ID: <_kE6DjeFjo523pxwcjvAk18TtDLEb-5MKRLL70FKT5w=.632c5a2c-8c10-45fc-a607-c3fdcd9d33d4@github.com>

On Tue, 25 May 2021 06:49:41 GMT, David Holmes <david.holmes at oracle.com> wrote:

> It isn't at all clear why it was necessary to introduce the io_sem just
so some gtest will pass. Why did these tests fail?

You brought up this issue when you ran into crashes. https://github.com/openjdk/jdk/pull/3135#issuecomment-845993038
Here is my analysis. AsyncLogWriter::flush() was unsafe.  Previously,  flush() only flushed data out of the buffer. yes, it try to write what it dequeued, but there's a race condition I didn't think of!

Here is the case:
A thread invokes AsyncLogWriter::flush() and the buffer is empty() at that time. Previously, write() returned because it had nothing to write. However, the following code in log writer thread may be executing in parallel!  


  while (!it.is_empty()) {
    AsyncLogMessage* e = it.next();
    char* msg = e->message();

    if (msg != nullptr) {
      e->output()->write_blocking(e->decorations(), msg);
      os::free(msg);
    }
  }

If that race condition happens, it's unsafe to read log files after AsyncLogWriter::flush(). log writer thread is writing them!
It's even not safe to destroy LogOutput instances here. (That's the byproduct bug I discovered).
https://github.com/openjdk/jdk/pull/3135/files#diff-64ba5a15efefc31cf8bc2b1c51100933075913fc8ed6028ad348197e086c3c33R287

How to guarantee file writings have done?  That's why I introduced _io_sem. 
Now write() acquires and releases _io_sem no matter what. Even the buffer is empty.
This can guarantee that the buffer used to be empty and all dequeued messages are written by flush(). 

After I strengthen `flush()`, I found I could even enable all unified logging tests in async mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From alanb at openjdk.java.net  Tue May 25 07:41:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 25 May 2021 07:41:08 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths
In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
Message-ID: <xkeN5H-_hwWbPjWDw5lxxghPLrs_DCoawXfGx2gNPxY=.79be27de-ef93-4346-a3e4-a6b2c88846ba@github.com>

On Mon, 24 May 2021 16:43:09 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
> 
> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
> 
> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
> 
> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
> 
> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
> 
> Results from Linux:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1
> 
> 
> Results from Windows 10:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
> ==============================
> TEST SUCCESS
> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> 
> 
> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1

test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java line 6:

> 4:  * Licensed under the Apache License, Version 2.0 (the "License");
> 5:  * you may not use this file except in compliance with the License.
> 6:  * You may obtain a copy of the License at

The test sources have Apache license, I thought we always used GPL for tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From xxinliu at amazon.com  Tue May 25 07:48:49 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Tue, 25 May 2021 00:48:49 -0700
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v21]
In-Reply-To: <14ecd7ba-61e0-355b-806c-8fd9edd8d7c4@oracle.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
 <14ecd7ba-61e0-355b-806c-8fd9edd8d7c4@oracle.com>
Message-ID: <505ae50e-88ce-ec10-9fea-dbaf6262c786@amazon.com>

hi, David,

I thought of your concern. now I think your concern is valid.

If the underlying filesystem or socket is defunct, this line is may be
blocking. _io_sem is now zero. As a result, we can't finish aborting if
we do invoke AsyncLogWriter::flush() in aborting process.

e->output()->write_blocking(e->decorations(), msg);

Technically speaking, termination has the same issue.
We have to take the risk in termination, or the log files are not
integral. I think lost logs are acceptable in abortion scenario.

Thanks,
--lx


On 5/24/21 11:52 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 25/05/2021 3:23 pm, Xin Liu wrote:
>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>> underlying files periodically.
>>
>> Xin Liu has updated the pull request incrementally with two additional commits since the last revision:
>>
>>   - Remove AsyncLogWriter::flush() from os::shutdown().
> 
> You should have waited till there was further discussion on this as
> there needs to be a consensus on what is needed here.
> 
> David
> -----
> 
>>     When jvm aborts, it won't invoke AsyncLogWriter::flush() and guarantee
>>     not to hinder the aborting process.
>>
>>     Run all unified logging tests in async mode.
>>   - Biased to the thread which is taking buffer lock.
>>
>> -------------
>>
>> Changes:
>>    - all: https://git.openjdk.java.net/jdk/pull/3135/files
>>    - new: https://git.openjdk.java.net/jdk/pull/3135/files/9800a8cc..2ffc33fe
>>
>> Webrevs:
>>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=20
>>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=19-20
>>
>>    Stats: 32 lines in 5 files changed: 7 ins; 15 del; 10 mod
>>    Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
>>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3135
>>

From aph at redhat.com  Tue May 25 09:04:34 2021
From: aph at redhat.com (Andrew Haley)
Date: Tue, 25 May 2021 10:04:34 +0100
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp
 iff 2.29 or greater on AArch64.
In-Reply-To: <0JcCtbFlWgnepu7qnSZXuPeupgsPfvvOR20Az_2dJSQ=.a365b573-0b5b-4358-a834-44db59128b0d@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
 <0JcCtbFlWgnepu7qnSZXuPeupgsPfvvOR20Az_2dJSQ=.a365b573-0b5b-4358-a834-44db59128b0d@github.com>
Message-ID: <f59a92f7-b857-ab52-504d-11ef9f1661e7@redhat.com>

On 5/24/21 7:50 PM, gregcawthorne wrote:
> On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne at openjdk.org> wrote:
>
> I have been reading up on the monotonicity paper suggested by Andrew Haley:
> [http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf](url)
>
> In order to try and see if I can prove the current glibc
> implementations of log and exp, for monotonicity.
>
> However, I have come to the conclusion that the paper
> calculates the relative error threshold for monotonicity for an
> approximation, and then relies on extra bits of floating-point
> hardware precision to be guaranteed monotonic. These extra bits
> of precision are greater than the target representations
> mantissa bits, which when subsequently rounded at the
> end (rounding is semi monotonic), leads to a monotonic
> implementation. No extra bits of floating-point precision are
> present in AArch64 in-between floating-point operations and so
> this paper won't help us in this case.

Indeed. I'm looking at some other references, and e.g. Muller,
Elementary Functions, provides an example that needs 2 guard bits
to round monotonically in the case of sin(x). I'm not sure that
it's possible to do the final rounding step in a way that
guarantees monotonicity without some guard bits. I can't find
anything that provides a way to do so.

[ One thing: Java uses the term "semi-monotomic" to
mean "whenever the mathematical function is non-decreasing, so is
the floating-point approximation, likewise, whenever the
mathematical function is non-increasing, so is the floating-point
approximation." I don't really understand what distinction means. ]

> If the remez polynomial of fdlibm isn?t definitively proven to be
> monotonic, and the glibcs remez polynomials has comparable
> accuracy. Then it might suffice to attempt to investigate further
> the effects of the table lookup method implementation; with regards
> to semi-monotonicity, even if it wouldn?t offer a total proof of the
> overall implementation.

Maybe so. In OpenJDK, Joe Darcy has done more work in this area than
anyone else, and we should get him involved.

-- 
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 adinn at openjdk.java.net  Tue May 25 09:37:06 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 25 May 2021 09:37:06 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
Message-ID: <WBgLB90ctsAcUPWU24ECorhVnSOtkdwJrTCQycQi57o=.803883ee-52a7-495d-8af9-144b55c89aa8@github.com>

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne at openjdk.org> wrote:

> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
> 
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux.cpp/hpp.
> This is then used to select the glibcs implementation of
> log, log10, exp at runtime for c1 and c2, iff we have
> glibc 2.29 or greater.
> 
> This will ensure OpenJDK can benefit from future improvements
> to glibc.
> 
> Glibc adheres to the ieee754 standard, unless stated otherwise
> in its spec.
> 
> As there are no stated exceptions in the current glibc spec
> for dlog, dlog10 and dexp, we can assume they currently follow
> ieee754 (which testing confirms). As such, future version of
> glibc are unlikely to lose this compliance with ieee754 in
> future.
> 
> W.r.t performance this patch sees ~15-30% performance improvements for
> log and log10, with ~50-80% performance improvements for exp for the
> common input ranged (which output real numbers). However for the NaN
> and inf output ranges we see a slow down of up to a factor of 2 for
> some functions and architectures.
> 
> Due to this being the uncommon case we assert that this is a
> worthwhile tradeoff.

> [ One thing: Java uses the term "semi-monotonic" to
> mean "whenever the mathematical function is non-decreasing, so is
> the floating-point approximation, likewise, whenever the
> mathematical function is non-increasing, so is the floating-point
> approximation." I don't really understand what distinction means. ]

I believe this is to allow for the fact that the function is continuous and the floating-point approximation is discrete.

Let F be the actual function and f the floating point approximation.  Assume we have two successive floating point values x, x'  and, without loss of generality, F(x) <= F(x'). What are the circumstances under which we require f(x) =< f(x')? Semi-monotonicity says that is only needed when F is non-decreasing on the interval [x, x']. Expressed more precisely, the condition that F is non-decreasing is

  for all y such that x =< y =< x' : F(x) <= F(y) <= F(x').

In other words:

  if the graph only ever stays level or increases across the interval [x, x'] then we must have f(x) =< f(x')

  If the graph wiggles *up* and *down* across the interval [x, x'] we can allow f(x) > f(x').

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From github.com+28651297+mkartashev at openjdk.java.net  Tue May 25 09:45:34 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Tue, 25 May 2021 09:45:34 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
Message-ID: <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>

> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
> 
> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
> 
> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
> 
> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
> 
> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
> 
> Results from Linux:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1
> 
> 
> Results from Windows 10:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
> ==============================
> TEST SUCCESS
> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> 
> 
> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1

Maxim Kartashev 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:

  8195129: System.load() fails to load from unicode paths

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4169/files
  - new: https://git.openjdk.java.net/jdk/pull/4169/files/265f7907..fe661dff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=00-01

  Stats: 55 lines in 3 files changed: 24 ins; 1 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169

PR: https://git.openjdk.java.net/jdk/pull/4169

From tibordigana at apache.org  Tue May 25 10:07:51 2021
From: tibordigana at apache.org (Tibor Digana)
Date: Tue, 25 May 2021 12:07:51 +0200
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <4f6d0b9d-946d-f911-57bf-e3b78d3fc011@oracle.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
 <4f6d0b9d-946d-f911-57bf-e3b78d3fc011@oracle.com>
Message-ID: <CAKuVzBSQkbDTBJpPzsipWzquy+6kchU3wKisy4A5dCM5d2AUWw@mail.gmail.com>

Hi David,

>> I'm not sure why you think the JVM should be comparable in size to the
native code used by the core libraries.
>> The JVM is a huge piece of native code in comparison to that used by the
core libraries.

Because Oracle had an ambition in the Jigsaw project to develop a modular
JDK and there are some consequences in the native JVM.
Nowadays the Java developers utilize the commands with JLINK and they say
that they are able to shrink the Java modules to cca 10MB.
Shrinking them more does not make sense because there is one file which is
much bigger - libjvm.so.
If we are asking about the effort spent in JLINK and the effectiveness of
JLINK, we have to say that we should continue with modularity on the JVM
level in order to make this process perfect.
It is not about me and how I write a native code.
It is about our understanding and how we would agree.
On one hand you can see the technical things but I can see the marketing
and a better reputation of Java especially in the world of Microservices
and embedded devices.

I am using BusyBox and Linux Alpine cca 2.7 MB, and so the libjvm.so ~ 22
MB is 8 times bigger.
We have to see the ambition of Java itself, e.g. jlink, and the movement
towards the Alpine and then we will see that the movement to the Alpine is
affected by the size of the JVM library.
I think the community has to make decisions on a higher level and we have
to understand these numbers.

Cheers
Tibor



Cheers
Tibor






On Tue, May 25, 2021 at 2:57 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Tibor,
>
> On 25/05/2021 5:26 am, Tibor Digana wrote:
> > Hi,
> >
> > The size of the library "libjvm.so"o is bigger than Java modules, and
> > bigger or comparable with the size of the application in the Docker
> image.
> >
> > After processing the JDK by the JLINK and shrinking the native library "
> > libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
> > big, i.e. 18MB (from the original size 22MB) and the modules have only
> 12MB.
> >
> > We have many GC algorithms in the JVM and maybe this is the reason why
> the
> > library is bigger than the Java modules and then JLINK does not become
> much
> > effective.
>
> I'm not sure why you think the JVM should be comparable in size to the
> native code used by the core libraries. The JVM is a huge piece of
> native code in comparison to that used by the core libraries.
>
> > Can you please develop a modular JVM library so that I would be able to
> > select only one algorithm of GC which means that the modules with other
> GC
> > algorithms would not appear in my Docker image?
>
> This can be built today (modulo some possible issues Stefan mentioned).
> You need to find an OpenJDK provider/distributor who is prepared to take
> on the cost of providing a selection of binaries with different VM
> features enabled.
>
> I've no idea how much size might be saved by stripping out different
> GC's today.
>
> Cheers,
> David
>
> > Thx
> > Tibor
> >
>

From adinn at redhat.com  Tue May 25 10:37:40 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 25 May 2021 11:37:40 +0100
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <CAKuVzBSQkbDTBJpPzsipWzquy+6kchU3wKisy4A5dCM5d2AUWw@mail.gmail.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
 <4f6d0b9d-946d-f911-57bf-e3b78d3fc011@oracle.com>
 <CAKuVzBSQkbDTBJpPzsipWzquy+6kchU3wKisy4A5dCM5d2AUWw@mail.gmail.com>
Message-ID: <3d342bbc-0029-7655-19f8-7b57017f2004@redhat.com>

On 25/05/2021 11:07, Tibor Digana wrote:
> I am using BusyBox and Linux Alpine cca 2.7 MB, and so the libjvm.so ~ 22
> MB is 8 times bigger.
> We have to see the ambition of Java itself, e.g. jlink, and the movement
> towards the Alpine and then we will see that the movement to the Alpine is
> affected by the size of the JVM library.
> I think the community has to make decisions on a higher level and we have
> to understand these numbers.
I understand why you might want a more lightweight JVM that can minimise 
resource usage. However, that's primarily going to require a saving in 
data footprint because most of the code in the JVM cannot be removed. It 
might well be possible to retune the code, say to trade off space 
against execution time. However, there is very little redundancy in 
terms of function. The GCs provide one significant exception, use of two 
JIT compilers in a tiered configuration is another.

However, I am unclear why you care so much about this redundancy in 
relation to the size of the library on disk? There may well be code for 
six different GCs in the library but only one of them will actually be 
executed at runtime. Similarly, you can limit the JVM to use just one 
JIT compiler by runnign with -XX:-TieredCompilation.

So, only one GC and, if you choose, only one JIT compiler will be 
consuming memory pages for the corresponding code and data pages in the 
image. Code or data pages for the unselected GCs will not incur physical 
memory costs. In other words the apparent bloat you see in having such 
redundant elements in the disk image will not be replicated by a 
comparable increment in the resident memory image.

So, can you explain: why *do* you care about the disk size of the 
library? Is the cost of disk space really a big issue vs other overheads 
such as the cost of the electricity to run the program? Is the time or 
network bandwidth required to provision an extra 20MBs of image onto a 
machine adding a significant amount to your costs?

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From aph at redhat.com  Tue May 25 11:33:16 2021
From: aph at redhat.com (Andrew Haley)
Date: Tue, 25 May 2021 12:33:16 +0100
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp
 iff 2.29 or greater on AArch64.
In-Reply-To: <WBgLB90ctsAcUPWU24ECorhVnSOtkdwJrTCQycQi57o=.803883ee-52a7-495d-8af9-144b55c89aa8@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
 <WBgLB90ctsAcUPWU24ECorhVnSOtkdwJrTCQycQi57o=.803883ee-52a7-495d-8af9-144b55c89aa8@github.com>
Message-ID: <ddd29a2f-cf66-3f47-6aee-1860f842b4c9@redhat.com>

On 5/25/21 10:37 AM, Andrew Dinn wrote:
>   if the graph only ever stays level or increases across the interval [x, x'] then we must have f(x) =< f(x')
> 
>   If the graph wiggles *up* and *down* across the interval [x, x'] we can allow f(x) > f(x').

Ah, OK. It's just that odd corner case. I think that probably only
happens in a few places such as sin(pi), and we don't attempt to use
a polynomial approximation that crosses such a range, so we have a
segment boundary at that point. (Guessing, but I haven't looked.)

-- 
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 aleksei.voitylov at bell-sw.com  Tue May 25 11:37:27 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 25 May 2021 14:37:27 +0300
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
Message-ID: <4a7abb5c-d21b-38e7-f537-a35ca464831c@bell-sw.com>

Tibor,

GC algorithms only account for a fraction of libjvm.so size. For
example, if you remove Epsilon, Parallel, CMS, Shenandoah, and G1 the
size of the JVM only reduces by ~3 MB. After stripping (iff you believe
this is a good trade-off) that reduces to ~ 2.5 Mb.

-Aleksei

On 24/05/2021 22:26, Tibor Digana wrote:
> Hi,
>
> The size of the library "libjvm.so"o is bigger than Java modules, and
> bigger or comparable with the size of the application in the Docker image.
>
> After processing the JDK by the JLINK and shrinking the native library "
> libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so" is too
> big, i.e. 18MB (from the original size 22MB) and the modules have only 12MB.
>
> We have many GC algorithms in the JVM and maybe this is the reason why the
> library is bigger than the Java modules and then JLINK does not become much
> effective.
>
> Can you please develop a modular JVM library so that I would be able to
> select only one algorithm of GC which means that the modules with other GC
> algorithms would not appear in my Docker image?
>
> Thx
> Tibor


From jiefu at openjdk.java.net  Tue May 25 11:57:28 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 25 May 2021 11:57:28 GMT
Subject: Integrated: 8267213: cpuinfo_segv is incorrectly triaged as execution
 protection violation on x86_32
In-Reply-To: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
References: <jQ-UMfHY4sMzHkaJFb75uo3CUPD2hUI5pKjqvxCCSrA=.d38dade9-914c-48ec-ad31-a9de3180571c@github.com>
Message-ID: <FJWh7654Dg1emJPxcEmnMBxcqjVd-o1HxSdBSInR_iQ=.3efed5dd-1c34-44be-8d81-ee7e1e0dd0a4@github.com>

On Mon, 17 May 2021 03:56:22 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> This is a follow-up of JDK-8260046.
> And it can be reproduced by `java -XX:UnguardOnExecutionViolation=1` on x86_32.
> Let's fix it
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: b403d399
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b403d3990894853d6e291c8ff8abb44bddb3c99f
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8267213: cpuinfo_segv is incorrectly triaged as execution protection violation on x86_32

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4044

From david.holmes at oracle.com  Tue May 25 12:57:18 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 May 2021 22:57:18 +1000
Subject: Modular LIBJVM.SO library for Docker
In-Reply-To: <CAKuVzBSQkbDTBJpPzsipWzquy+6kchU3wKisy4A5dCM5d2AUWw@mail.gmail.com>
References: <CAKuVzBRrXrRbM-uan3YjZ6CFppp5G7TEJ+2fVJ0pOH_O=cEhiw@mail.gmail.com>
 <4f6d0b9d-946d-f911-57bf-e3b78d3fc011@oracle.com>
 <CAKuVzBSQkbDTBJpPzsipWzquy+6kchU3wKisy4A5dCM5d2AUWw@mail.gmail.com>
Message-ID: <de721250-28f9-fa26-0535-1638016b7ec9@oracle.com>

On 25/05/2021 8:07 pm, Tibor Digana wrote:
> Hi David,
> 
>  >> I'm not sure why you think the JVM should be comparable in size to 
> the native code used by the core libraries.
>  >> The JVM is a huge piece of native code in comparison to that used by 
> the core libraries.
> 
> Because Oracle had an ambition in the Jigsaw project to develop a 
> modular JDK and there are some consequences in the native JVM.

The JVM can be built with various subcomponents present or absent as 
already stated. How that gets incorporated into a "modular JDK" and used 
with a tool like Jlink is not a question for hotspot-dev - possibly 
jdk-dev would be more appropriate. But there are non-technical 
constraints about what kind of stripped-down JDK you can ship and still 
call it Java. We went down this road in Java 8 with Compact Profiles and 
the MinimalVM.

Cheers,
David
-----

> Nowadays the Java developers utilize the commands with JLINK and they 
> say that they are able to shrink the Java modules to cca 10MB.
> Shrinking them more does not make sense because there is one file which 
> is much bigger - libjvm.so.
> If we are asking about the effort spent in JLINK and the effectiveness 
> of JLINK, we have to say that we should continue with modularity on the 
> JVM level in order to make this process perfect.
> It is not about me and how I write a native code.
> It is about our understanding and how we would agree.
> On one hand you can see the technical things but I can see the marketing 
> and a better reputation of Java especially in the world of Microservices 
> and embedded devices.
> I am using BusyBox and Linux Alpine cca 2.7 MB, and so the libjvm.so ~ 
> 22 MB is 8 times bigger.
> We have to see the ambition of Java itself, e.g. jlink, and the movement 
> towards the Alpine and then we will see that the movement to?the Alpine 
> is affected by the size of the JVM library.
> I think the community has to make decisions on a higher level and we 
> have to understand these numbers.
> 
> Cheers
> Tibor
> 
> 
> 
> Cheers
> Tibor
> 
> 
> 
> 
> 
> 
> On Tue, May 25, 2021 at 2:57 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Tibor,
> 
>     On 25/05/2021 5:26 am, Tibor Digana wrote:
>      > Hi,
>      >
>      > The size of the library "libjvm.so"o is bigger than Java modules, and
>      > bigger or comparable with the size of the application in the
>     Docker image.
>      >
>      > After processing the JDK by the JLINK and shrinking the native
>     library "
>      > libjvm.so" my JRE is 35MB big in Docker image but the "libjvm.so"
>     is too
>      > big, i.e. 18MB (from the original size 22MB) and the modules have
>     only 12MB.
>      >
>      > We have many GC algorithms in the JVM and maybe this is the
>     reason why the
>      > library is bigger than the Java modules and then JLINK does not
>     become much
>      > effective.
> 
>     I'm not sure why you think the JVM should be comparable in size to the
>     native code used by the core libraries. The JVM is a huge piece of
>     native code in comparison to that used by the core libraries.
> 
>      > Can you please develop a modular JVM library so that I would be
>     able to
>      > select only one algorithm of GC which means that the modules with
>     other GC
>      > algorithms would not appear in my Docker image?
> 
>     This can be built today (modulo some possible issues Stefan mentioned).
>     You need to find an OpenJDK provider/distributor who is prepared to
>     take
>     on the cost of providing a selection of binaries with different VM
>     features enabled.
> 
>     I've no idea how much size might be saved by stripping out different
>     GC's today.
> 
>     Cheers,
>     David
> 
>      > Thx
>      > Tibor
>      >
> 

From coleenp at openjdk.java.net  Tue May 25 13:27:16 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 25 May 2021 13:27:16 GMT
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes
Message-ID: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>

Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
Tested with tier 2-3 and tier1 in progress.
Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).

-------------

Commit messages:
 - 8267653: Remove Mutex::_safepoint_check_sometimes

Changes: https://git.openjdk.java.net/jdk/pull/4184/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4184&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267653
  Stats: 22 lines in 5 files changed: 0 ins; 19 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4184.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4184/head:pull/4184

PR: https://git.openjdk.java.net/jdk/pull/4184

From github.com+4146708+a74nh at openjdk.java.net  Tue May 25 15:01:58 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 25 May 2021 15:01:58 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <Lnqxm9SCDsX31hnNtnRmS4nMKJHAefuFYKr2qnXdUcY=.116d7d02-5e1c-4fc9-bfbc-559f0932bb8f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <Lnqxm9SCDsX31hnNtnRmS4nMKJHAefuFYKr2qnXdUcY=.116d7d02-5e1c-4fc9-bfbc-559f0932bb8f@github.com>
Message-ID: <ECrKgJDlb_EFKKwT4AdcbJg1DxyhOg1jPxyaIhhquq8=.60129f76-0839-440d-9e1e-f945ead0d856@github.com>

On Mon, 24 May 2021 19:56:10 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please let me know if I understand things correctly:
> 
> Apple's **M1** is **arm64e** architecture, so therefore it is **PAC** architecture, however, currently that's only active in **iOS**.
> 
> **macOS** does not currently support **PAC**, but we're adding the support to be ready whenever Apple decides to turn it on?
> 

MacOS does support PAC, but it's an experimental feature that needs enabling at machine boot up.
For example, all the standard tools in /bin are built for arm64e, and when they are run, the PAC instructions are treated as NOPs.

Apple could turn on PAC as default at any time, and any app compiled for arm64e will suddenly be PAC protected. I suspect we'll have a little warning first. Given that I was adding the fix for Linux, it made sense to also proactively fix MacOS at the same time.


> On **PAC** systems the following code:
> 
> `ptrauth_strip(&strcpy, ptrauth_key_asib) == &strcpy`
> 
> would be false, and on **non PAC** OS , like for now **macOS** it will always be true (since ptrauth_strip is a NOP macro), is that correct?

Assuming that  &strcpy is a signed pointer, then yes - it will be false on a PAC enabled OS.
If the pointer isn't signed or PAC is disabled, then it will be true.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From gziemski at openjdk.java.net  Tue May 25 15:25:56 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Tue, 25 May 2021 15:25:56 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <ECrKgJDlb_EFKKwT4AdcbJg1DxyhOg1jPxyaIhhquq8=.60129f76-0839-440d-9e1e-f945ead0d856@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <Lnqxm9SCDsX31hnNtnRmS4nMKJHAefuFYKr2qnXdUcY=.116d7d02-5e1c-4fc9-bfbc-559f0932bb8f@github.com>
 <ECrKgJDlb_EFKKwT4AdcbJg1DxyhOg1jPxyaIhhquq8=.60129f76-0839-440d-9e1e-f945ead0d856@github.com>
Message-ID: <pPX2yTUx8nkeQ4EK5rhv1o5kHyhkNxLhPo2KnfpIsIA=.05d8b11a-47e5-45f7-9622-213bb13edb44@github.com>

On Tue, 25 May 2021 14:59:25 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> > Please let me know if I understand things correctly:
> > Apple's **M1** is **arm64e** architecture, so therefore it is **PAC** architecture, however, currently that's only active in **iOS**.
> > **macOS** does not currently support **PAC**, but we're adding the support to be ready whenever Apple decides to turn it on?
> 
> MacOS does support PAC, but it's an experimental feature that needs enabling at machine boot up.
> For example, all the standard tools in /bin are built for arm64e, and when they are run, the PAC instructions are treated as NOPs.
> 
> Apple could turn on PAC as default at any time, and any app compiled for arm64e will suddenly be PAC protected. I suspect we'll have a little warning first. Given that I was adding the fix for Linux, it made sense to also proactively fix MacOS at the same time.
> 
> > On **PAC** systems the following code:
> > `ptrauth_strip(&strcpy, ptrauth_key_asib) == &strcpy`
> > would be false, and on **non PAC** OS , like for now **macOS** it will always be true (since ptrauth_strip is a NOP macro), is that correct?
> 
> Assuming that &strcpy is a signed pointer, then yes - it will be false on a PAC enabled OS.
> If the pointer isn't signed or PAC is disabled, then it will be true.

So currently, there is no way, by default, to test PAC on macOS. Is it turned on by default on Linux arrch64 starting at some OS version, or is it optional like macOS?

Did you give any thoughts to writing gtests that exercise these new PAC related functionality?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From gziemski at openjdk.java.net  Tue May 25 15:35:04 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Tue, 25 May 2021 15:35:04 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <pPX2yTUx8nkeQ4EK5rhv1o5kHyhkNxLhPo2KnfpIsIA=.05d8b11a-47e5-45f7-9622-213bb13edb44@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <Lnqxm9SCDsX31hnNtnRmS4nMKJHAefuFYKr2qnXdUcY=.116d7d02-5e1c-4fc9-bfbc-559f0932bb8f@github.com>
 <ECrKgJDlb_EFKKwT4AdcbJg1DxyhOg1jPxyaIhhquq8=.60129f76-0839-440d-9e1e-f945ead0d856@github.com>
 <pPX2yTUx8nkeQ4EK5rhv1o5kHyhkNxLhPo2KnfpIsIA=.05d8b11a-47e5-45f7-9622-213bb13edb44@github.com>
Message-ID: <nlLwddJq8sDbWTvWa7IkNAsXt-e9IxSsCzRICzE5OiE=.d386fc8b-3317-454c-9807-76d2cb81c3e2@github.com>

On Tue, 25 May 2021 15:23:11 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> > MacOS does support PAC, but it's an experimental feature that needs enabling at machine boot up.

I can only seem to find info on how to enable/disable System Integrity Protection, how exactly do you do it for PAC?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+73799211+gregcawthorne at openjdk.java.net  Tue May 25 15:35:57 2021
From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne)
Date: Tue, 25 May 2021 15:35:57 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
Message-ID: <dZFj7BhCpn5Zck-034NRajve8FcMp5OjO7MBLc2cnZM=.8ec477a5-8cc7-4db9-8bc8-7403cc37c6b9@github.com>

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne at openjdk.org> wrote:

> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
> 
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux.cpp/hpp.
> This is then used to select the glibcs implementation of
> log, log10, exp at runtime for c1 and c2, iff we have
> glibc 2.29 or greater.
> 
> This will ensure OpenJDK can benefit from future improvements
> to glibc.
> 
> Glibc adheres to the ieee754 standard, unless stated otherwise
> in its spec.
> 
> As there are no stated exceptions in the current glibc spec
> for dlog, dlog10 and dexp, we can assume they currently follow
> ieee754 (which testing confirms). As such, future version of
> glibc are unlikely to lose this compliance with ieee754 in
> future.
> 
> W.r.t performance this patch sees ~15-30% performance improvements for
> log and log10, with ~50-80% performance improvements for exp for the
> common input ranged (which output real numbers). However for the NaN
> and inf output ranges we see a slow down of up to a factor of 2 for
> some functions and architectures.
> 
> Due to this being the uncommon case we assert that this is a
> worthwhile tradeoff.

greg.cawthorne at arm.com

Should work

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From vkempik at openjdk.java.net  Tue May 25 16:11:54 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 25 May 2021 16:11:54 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
Message-ID: <w0s7PqTb4dAgUDkG5Iv_dAyaL4OLqOb3xDI3GfocGtE=.a93a046d-4d77-452b-9726-3b73ea7806b9@github.com>

On Fri, 21 May 2021 11:07:14 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure pointer is stripped on macos
>   
>   Change-Id: Idcf5f08e87c1e1f5af1dc8f421f8c7efc3d9c4c2
>   CustomizedGitHooks: yes

Hello
I don't think that's correct description of current PAC state on macos11
if binary is of type arm64e then it has pac enabled and it works. (most of system binaries are already arm64e, also the kernel and kernel extensions are arm64e already)
To be able to test your own arm64e binary one need to add to boot-args ( https://developer.apple.com/documentation/driverkit/debugging_and_testing_system_extensions?language=objc ) -arm64e_preview_abi, otherwise the kernel won't allow custom arm64e app to start.

But, there is one thing, the shared library cache is arm64e only ( check folder /System/Library/dyld), and all of  few remaining dylibs ( check any in /usr/lib) is arm64e only ( plus x86_64). arm64 apps use arm64e libs.
All of these arm64e libs use PAC and it works ( not disabled/NOP-ed), as a result we had a bug recently - https://bugs.openjdk.java.net/browse/JDK-8267235

jvm probably needs to sanitize any pointer coming from native libs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From sviswanathan at openjdk.java.net  Tue May 25 20:19:04 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 25 May 2021 20:19:04 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v14]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <IYZ96BDzAKfLh2qNN4RVCJpu5uP7zA1VgbmYbjSd4BM=.a34dbc97-1abf-4e2c-9f9a-8ad8cce40b8b@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Javadoc changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/4d59af0a..6cd50248

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=12-13

  Stats: 58 lines in 1 file changed: 38 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From gziemski at openjdk.java.net  Tue May 25 21:44:24 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Tue, 25 May 2021 21:44:24 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
Message-ID: <_RF42fybublrrONFhG88jYkGxklihFJo4bJXnHkvKmE=.a7e74140-277e-48f7-b4b4-244ba29c2108@github.com>

On Fri, 21 May 2021 11:07:14 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure pointer is stripped on macos
>   
>   Change-Id: Idcf5f08e87c1e1f5af1dc8f421f8c7efc3d9c4c2
>   CustomizedGitHooks: yes

I see this pattern repeating:


   address sender_pc = this->sender_pc();
   // Interpreter should never sign the return address.
   assert(pauth_ptr_is_raw(sender_pc), "cannot be signed");

   return frame(sender_sp, unextended_sp, link(), sender_pc);


Why can't we just add the **assert** to the **frame()** constructor instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From sviswanathan at openjdk.java.net  Tue May 25 22:02:39 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 25 May 2021 22:02:39 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v15]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <ZxHWkBVoAtQHj-z9ygPhJP2wPRcFR3p9s3fpYO4T2Cg=.1caa8717-820c-4139-8240-819c4b93be02@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  correct javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/6cd50248..e5208a18

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=13-14

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sspitsyn at openjdk.java.net  Tue May 25 22:39:15 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 25 May 2021 22:39:15 GMT
Subject: RFR: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <FZ5yWJjMLyZghEvkkBfTm6e_hT8GcdJS18agd27EJFc=.576d6ae0-fb84-401c-9916-830d954c836f@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

Hi Albert,
Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4146

From dholmes at openjdk.java.net  Tue May 25 23:06:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 25 May 2021 23:06:14 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
Message-ID: <JJ2sP-JmHk_FqKvNN5nNupat_4C05iDLnnhJ6ftzj3s=.51e6bcba-1a1e-44e0-9788-68889cca4506@github.com>

On Mon, 24 May 2021 12:58:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update HotSpot style guide documents

doc/hotspot-style.html line 97:

> 95: <li><p>Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.</p></li>
> 96: <li><p>.inline.hpp files should only be included in .cpp or .inline.hpp files.</p></li>
> 97: <li><p>All .inline.hpp files should include their corresponding .hpp file as the first include line. Externally used declarations should be put in the .hpp file, and not in the the .inline.hpp file. This rule exists to resolve problems with circular dependencies between.inline.hpp files.</p></li>

typo: the the
Need space after between on last line

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From github.com+58006833+xbzhang99 at openjdk.java.net  Wed May 26 00:00:18 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Wed, 26 May 2021 00:00:18 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86
In-Reply-To: <GLq7FGX_iiix9eq0cuAcOTdIC2auEyjcj4ihLAULKI8=.70989a95-1b9c-4ce5-adce-e89825eaa81e@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
 <GLq7FGX_iiix9eq0cuAcOTdIC2auEyjcj4ihLAULKI8=.70989a95-1b9c-4ce5-adce-e89825eaa81e@github.com>
Message-ID: <zkvNpQHvLelCdFPtXSw5iSshdyDdcXUWvdc71oQQis4=.f9fdcb03-bf4c-4aa7-a2c5-f7bc2414a6c2@github.com>

On Thu, 8 Apr 2021 15:29:56 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> If this is an optimization, do you have any numbers that show an improvement with this change?

@gerard-ziemski Hi, could you review the patch? thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3334

From dholmes at openjdk.java.net  Wed May 26 00:52:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 26 May 2021 00:52:13 GMT
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes
In-Reply-To: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
Message-ID: <aF7Vsfq_1jsJpPVOpDffrBm4FSux_PRvJqJfC_iiFyI=.58fad6e7-f200-4f95-90ec-f6dcec8eb5de@github.com>

On Tue, 25 May 2021 13:20:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
> Tested with tier 2-3 and tier1 in progress.
> Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).

Hi Coleen,

This seems fine. Working through the thread and VM termination logic is always tricky. Just to be clear the condition for the mutex not checking safepoints is that the thread has terminated, not just that it is exiting, so I've suggested an additional assert before taking the Heap-lock.

Thanks,
David

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 543:

> 541:   } else {
> 542:     // Heap_lock protects external pending list
> 543:     MonitorLocker ml(Heap_lock);

For performance you could leave the _no_safepoint_check flag.

src/hotspot/share/runtime/thread.cpp line 3420:

> 3418:     // we'll never emerge out of the safepoint before the VM exits.
> 3419: 
> 3420:     MutexLocker ml(Heap_lock);

Can you add an assert before this that the thread is_terminated() as that is the key to the mutex acquisition not doing a safepoint check.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4184

From coleenp at openjdk.java.net  Wed May 26 01:53:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 26 May 2021 01:53:33 GMT
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes [v2]
In-Reply-To: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
Message-ID: <Vlg6EpsZj7VNzjxfLXoA-mwseSNfctrdUPfqFoX98Vg=.6b8be221-b1dd-476b-8596-45c0d4d5fcc6@github.com>

> Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
> Tested with tier 2-3 and tier1 in progress.
> Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add assert that the thread is terminated before taking Heap_lock

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4184/files
  - new: https://git.openjdk.java.net/jdk/pull/4184/files/d7f55efe..3dc9b3b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4184&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4184&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4184.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4184/head:pull/4184

PR: https://git.openjdk.java.net/jdk/pull/4184

From coleenp at openjdk.java.net  Wed May 26 01:53:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 26 May 2021 01:53:34 GMT
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes [v2]
In-Reply-To: <aF7Vsfq_1jsJpPVOpDffrBm4FSux_PRvJqJfC_iiFyI=.58fad6e7-f200-4f95-90ec-f6dcec8eb5de@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
 <aF7Vsfq_1jsJpPVOpDffrBm4FSux_PRvJqJfC_iiFyI=.58fad6e7-f200-4f95-90ec-f6dcec8eb5de@github.com>
Message-ID: <IxSp6HN-X-jvxdg6k5oNY9U3edaagjutslwW-pbn7l8=.e98b7711-1f28-4a50-850b-91ad888fbb19@github.com>

On Wed, 26 May 2021 00:38:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add assert that the thread is terminated before taking Heap_lock
>
> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 543:
> 
>> 541:   } else {
>> 542:     // Heap_lock protects external pending list
>> 543:     MonitorLocker ml(Heap_lock);
> 
> For performance you could leave the _no_safepoint_check flag.

I cannot leave it because there's an assert to verify that we don't try to take this lock without a safepoint check, since it was declared with safepoint_check_always.

> src/hotspot/share/runtime/thread.cpp line 3420:
> 
>> 3418:     // we'll never emerge out of the safepoint before the VM exits.
>> 3419: 
>> 3420:     MutexLocker ml(Heap_lock);
> 
> Can you add an assert before this that the thread is_terminated() as that is the key to the mutex acquisition not doing a safepoint check.

Ok, I can add:
+    assert(thread->is_terminated(), "must be terminated before acquiring Heap_lock");
and rerun tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4184

From david.holmes at oracle.com  Wed May 26 02:00:08 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 26 May 2021 12:00:08 +1000
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes [v2]
In-Reply-To: <IxSp6HN-X-jvxdg6k5oNY9U3edaagjutslwW-pbn7l8=.e98b7711-1f28-4a50-850b-91ad888fbb19@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
 <aF7Vsfq_1jsJpPVOpDffrBm4FSux_PRvJqJfC_iiFyI=.58fad6e7-f200-4f95-90ec-f6dcec8eb5de@github.com>
 <IxSp6HN-X-jvxdg6k5oNY9U3edaagjutslwW-pbn7l8=.e98b7711-1f28-4a50-850b-91ad888fbb19@github.com>
Message-ID: <781224c1-0118-19b4-6cc8-3c8621af4d43@oracle.com>

On 26/05/2021 11:53 am, Coleen Phillimore wrote:
> On Wed, 26 May 2021 00:38:00 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Add assert that the thread is terminated before taking Heap_lock
>>
>> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 543:
>>
>>> 541:   } else {
>>> 542:     // Heap_lock protects external pending list
>>> 543:     MonitorLocker ml(Heap_lock);
>>
>> For performance you could leave the _no_safepoint_check flag.
> 
> I cannot leave it because there's an assert to verify that we don't try to take this lock without a safepoint check, since it was declared with safepoint_check_always.

But that assert only applies to JavaThreads and this is being taken by a 
GC thread isn't it?

>> src/hotspot/share/runtime/thread.cpp line 3420:
>>
>>> 3418:     // we'll never emerge out of the safepoint before the VM exits.
>>> 3419:
>>> 3420:     MutexLocker ml(Heap_lock);
>>
>> Can you add an assert before this that the thread is_terminated() as that is the key to the mutex acquisition not doing a safepoint check.
> 
> Ok, I can add:
> +    assert(thread->is_terminated(), "must be terminated before acquiring Heap_lock");
> and rerun tests.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4184
> 

From dholmes at openjdk.java.net  Wed May 26 02:21:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 26 May 2021 02:21:11 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
Message-ID: <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>

On Mon, 24 May 2021 12:58:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update HotSpot style guide documents

Hi Stefan,

I think this policy makes a lot of sense!

I only scanned through the changes to get a sense of them but it all seemed fine.

Thanks,
David

doc/hotspot-style.md line 142:

> 140: 
> 141: * All .inline.hpp files should include their corresponding .hpp file
> 142: as the first include line. Externally used declarations should be put

Do we need to spell out it should be first unless precompiled.hpp is included?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From coleen.phillimore at oracle.com  Wed May 26 03:05:52 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 25 May 2021 23:05:52 -0400
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes [v2]
In-Reply-To: <781224c1-0118-19b4-6cc8-3c8621af4d43@oracle.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
 <aF7Vsfq_1jsJpPVOpDffrBm4FSux_PRvJqJfC_iiFyI=.58fad6e7-f200-4f95-90ec-f6dcec8eb5de@github.com>
 <IxSp6HN-X-jvxdg6k5oNY9U3edaagjutslwW-pbn7l8=.e98b7711-1f28-4a50-850b-91ad888fbb19@github.com>
 <781224c1-0118-19b4-6cc8-3c8621af4d43@oracle.com>
Message-ID: <82a3fbab-ea30-1bad-6600-4d52b874712f@oracle.com>



On 5/25/21 10:00 PM, David Holmes wrote:
> On 26/05/2021 11:53 am, Coleen Phillimore wrote:
>> On Wed, 26 May 2021 00:38:00 GMT, David Holmes <dholmes at openjdk.org> 
>> wrote:
>>
>>>> Coleen Phillimore has updated the pull request incrementally with 
>>>> one additional commit since the last revision:
>>>>
>>>> ?? Add assert that the thread is terminated before taking Heap_lock
>>>
>>> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp 
>>> line 543:
>>>
>>>> 541:?? } else {
>>>> 542:???? // Heap_lock protects external pending list
>>>> 543:???? MonitorLocker ml(Heap_lock);
>>>
>>> For performance you could leave the _no_safepoint_check flag.
>>
>> I cannot leave it because there's an assert to verify that we don't 
>> try to take this lock without a safepoint check, since it was 
>> declared with safepoint_check_always.
>
> But that assert only applies to JavaThreads and this is being taken by 
> a GC thread isn't it?

It's true that if this is a non-Java thread, it wouldn't fire the assert 
that checks that the states are consistent.? I had to go study the code 
a bit to see that, which I wouldn't want to do over again.? But it would 
be very inconsistent in the code since all other Heap_lock acquisitions 
are not made with _no_safepoint_check, we would have to look again to 
see why this is special and other GC threads take Heap_lock without 
no_safepoint_check.

And it wouldn't be a meaningful optimization.

thanks,
Coleen

>
>>> src/hotspot/share/runtime/thread.cpp line 3420:
>>>
>>>> 3418:???? // we'll never emerge out of the safepoint before the VM 
>>>> exits.
>>>> 3419:
>>>> 3420:???? MutexLocker ml(Heap_lock);
>>>
>>> Can you add an assert before this that the thread is_terminated() as 
>>> that is the key to the mutex acquisition not doing a safepoint check.
>>
>> Ok, I can add:
>> +??? assert(thread->is_terminated(), "must be terminated before 
>> acquiring Heap_lock");
>> and rerun tests.
>
> Thanks,
> David
>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4184
>>


From david.holmes at oracle.com  Wed May 26 05:40:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 26 May 2021 15:40:07 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
In-Reply-To: <_kE6DjeFjo523pxwcjvAk18TtDLEb-5MKRLL70FKT5w=.632c5a2c-8c10-45fc-a607-c3fdcd9d33d4@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <fc63fad7-b267-0271-a484-d242ff2b6711@oracle.com>
 <_kE6DjeFjo523pxwcjvAk18TtDLEb-5MKRLL70FKT5w=.632c5a2c-8c10-45fc-a607-c3fdcd9d33d4@github.com>
Message-ID: <d74e33e3-a072-4ed7-0c50-d59481caeb99@oracle.com>



On 25/05/2021 5:30 pm, Xin Liu wrote:
> On Tue, 25 May 2021 06:49:41 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> It isn't at all clear why it was necessary to introduce the io_sem just
> so some gtest will pass. Why did these tests fail?
> 
> You brought up this issue when you ran into crashes. https://github.com/openjdk/jdk/pull/3135#issuecomment-845993038

Yes but I was unclear why these tests were failing the way they were.

> Here is my analysis. AsyncLogWriter::flush() was unsafe.  Previously,  flush() only flushed data out of the buffer. yes, it try to write what it dequeued, but there's a race condition I didn't think of!
> 
> Here is the case:
> A thread invokes AsyncLogWriter::flush() and the buffer is empty() at that time. Previously, write() returned because it had nothing to write. However, the following code in log writer thread may be executing in parallel!
> 
> 
>    while (!it.is_empty()) {
>      AsyncLogMessage* e = it.next();
>      char* msg = e->message();
> 
>      if (msg != nullptr) {
>        e->output()->write_blocking(e->decorations(), msg);
>        os::free(msg);
>      }
>    }
> 
> If that race condition happens, it's unsafe to read log files after AsyncLogWriter::flush(). log writer thread is writing them!

If I understand what you are saying the issue was not the flush() itself 
but the fact that we could continue past the flush() and call 
LogConfiguration::finalize() while the writer thread was still writing 
out messages.

So really what that was indicating was a failure to synchronize with the 
writer thread during "shutdown". That could cause a crash or simply 
result in missing log output.

> It's even not safe to destroy LogOutput instances here. (That's the byproduct bug I discovered).
> https://github.com/openjdk/jdk/pull/3135/files#diff-64ba5a15efefc31cf8bc2b1c51100933075913fc8ed6028ad348197e086c3c33R287
> 
> How to guarantee file writings have done?  That's why I introduced _io_sem.
> Now write() acquires and releases _io_sem no matter what. Even the buffer is empty.
> This can guarantee that the buffer used to be empty and all dequeued messages are written by flush().

Okay so let me walk through this:

- Some logging happens and writer thread is logically woken up but 
doesn't yet execute.
- a shutdown occurs and we reach the point where we call 
LogConfiguration::finalize() which calls disable_outputs()
- at this point no new logging is possible
- we then have a race between the shutdown thread calling flush() and 
the async writer thread
- whomever gets the AsyncLogLock first claims all the buffered messages 
and will write them out
- if the shutdown thread wins there is no problem, the async writer 
thread will just redo _sem.wait()
- if the async writer thread wins we need the shutdown thread to wait 
until the async writer has finished writing

So we could at this point do some direct kind of "handshake" between the 
shutdown thread and the async writer thread to coordinate them. But 
instead the _iosem is introduced. The async writer thread holds the 
_iosem for the duration of the writing. The shutdown thread, after 
finding no messages buffered, can't acquire the _iosem until the async 
writer is done.

Okay I understand the protocol now.


> After I strengthen `flush()`, I found I could even enable all unified logging tests in async mode.

So again prior to this the real problem was a race between final logging 
output and VM termination, that could result in either crashes or lost 
logs messages, which in turn could cause test failures.

At one stage I believe you had intended to terminate the async writer 
thread, and that would have fixed the problem as well - assuming you 
handled the termination properly.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From stefank at openjdk.java.net  Wed May 26 06:38:47 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 06:38:47 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v5]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <c-OaKR1PFHIGfLRVAIG-RHC5EnozbxTHzTMq_5TRl_g=.140285a5-9230-4931-9679-8945670749d8@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review dholmes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/ba9ad1b1..0cf6257d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Wed May 26 06:38:53 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 06:38:53 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
 <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>
Message-ID: <O9teAMehggUiNNgTYGybK7Y7096B-qRUJy9GCCbUFhU=.4ab3e9e9-7a4f-437f-96f1-09125677e709@github.com>

On Wed, 26 May 2021 02:18:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Stefan,
> 
> I think this policy makes a lot of sense!
> 
> I only scanned through the changes to get a sense of them but it all seemed fine.
> 
> Thanks,
> David

Thanks a lot for reviewing!

> doc/hotspot-style.html line 97:
> 
>> 95: <li><p>Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.</p></li>
>> 96: <li><p>.inline.hpp files should only be included in .cpp or .inline.hpp files.</p></li>
>> 97: <li><p>All .inline.hpp files should include their corresponding .hpp file as the first include line. Externally used declarations should be put in the .hpp file, and not in the the .inline.hpp file. This rule exists to resolve problems with circular dependencies between.inline.hpp files.</p></li>
> 
> typo: the the
> Need space after between on last line

Fixed.

> doc/hotspot-style.md line 142:
> 
>> 140: 
>> 141: * All .inline.hpp files should include their corresponding .hpp file
>> 142: as the first include line. Externally used declarations should be put
> 
> Do we need to spell out it should be first unless precompiled.hpp is included?

We should never include precompiled.hpp from an .inline.hpp file, so I don't think we need to state that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From ayang at openjdk.java.net  Wed May 26 06:53:17 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 26 May 2021 06:53:17 GMT
Subject: RFR: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <4yHlfwn57DzEGk0FzmvZpC-x5811b8e0gvTaeeEw-5w=.340ae43e-9293-4623-8c1e-d1de77eb41bd@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4146

From ayang at openjdk.java.net  Wed May 26 06:53:17 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 26 May 2021 06:53:17 GMT
Subject: Integrated: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <FeJKq4QLFdLy3GuWZIeJCdW4tJaWBdy_QuoOo7FU8rk=.990baf26-a7a7-473b-a406-b9a1a0337cbd@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

This pull request has now been integrated.

Changeset: 03944168
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/039441689d21f3dccf515bb2be89608b0772a235
Stats:     45 lines in 4 files changed: 2 ins; 0 del; 43 mod

8267468: Rename refill waster counters in ThreadLocalAllocBuffer

Reviewed-by: kbarrett, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4146

From dholmes at openjdk.java.net  Wed May 26 07:56:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 26 May 2021 07:56:13 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <O9teAMehggUiNNgTYGybK7Y7096B-qRUJy9GCCbUFhU=.4ab3e9e9-7a4f-437f-96f1-09125677e709@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
 <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>
 <O9teAMehggUiNNgTYGybK7Y7096B-qRUJy9GCCbUFhU=.4ab3e9e9-7a4f-437f-96f1-09125677e709@github.com>
Message-ID: <zblvBz4I_k_n6eghRSSvY3Y4RqM6QUS7BqqBiT3JYlA=.6cd16585-e5c4-4a8c-ba73-6fadce910632@github.com>

On Wed, 26 May 2021 06:35:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> doc/hotspot-style.md line 142:
>> 
>>> 140: 
>>> 141: * All .inline.hpp files should include their corresponding .hpp file
>>> 142: as the first include line. Externally used declarations should be put
>> 
>> Do we need to spell out it should be first unless precompiled.hpp is included?
>
> We should never include precompiled.hpp from an .inline.hpp file, so I don't think we need to state that.

Ah. Right. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From tschatzl at openjdk.java.net  Wed May 26 08:14:13 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 May 2021 08:14:13 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <LpBhjn3dewyfqTrgaJr1iHj5JubJdrKI_5IR2GXm1OQ=.236a29ac-cd55-42ca-8071-81ac88747d43@github.com>

On Mon, 24 May 2021 11:11:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4163

From aph at openjdk.java.net  Wed May 26 08:29:13 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 26 May 2021 08:29:13 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
Message-ID: <o4DpcvHhgqpH1Lq310kbD4NmafJchP9Y0fYcn19e3cI=.32073d50-0f24-4f2d-bf04-a1815bea6ce7@github.com>

On Fri, 21 May 2021 11:07:14 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure pointer is stripped on macos
>   
>   Change-Id: Idcf5f08e87c1e1f5af1dc8f421f8c7efc3d9c4c2
>   CustomizedGitHooks: yes

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 516:

> 514:   // to the stack. In addition, we do not know which key was used to sign it.
> 515:   // Therefore, all we can do is strip it.
> 516:   address sender_pc = pauth_strip_pointer(this->sender_pc());

Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From kbarrett at openjdk.java.net  Wed May 26 08:35:12 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 May 2021 08:35:12 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <w70CN0tyk0gbdHP9xiIghaLTFz0Uv_ckHINXPgPjEew=.637a5ec8-d276-4be9-9319-f98df0a2e131@github.com>

On Mon, 24 May 2021 11:11:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/utilities/globalDefinitions.hpp line 155:

> 153: 
> 154: // Convert pointer to intptr_t, for use in printing pointers.
> 155: inline intptr_t p2i(const void* p) {

I don't think the `const void*` overload is needed, given the presence of the `const volatile void*` overload.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4163

From sjohanss at openjdk.java.net  Wed May 26 09:07:14 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 26 May 2021 09:07:14 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets
In-Reply-To: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
Message-ID: <z413Kwj8WvIX6uHeu8znszaLX1OBRCOVwrpDLo7rBHo=.f597dee6-e475-4d1f-824a-fddd4994f816@github.com>

On Wed, 19 May 2021 15:23:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
> 
>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
> 
> Over time many problems with performance and in particular memory usage have been observed:
> 
> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
> 
> * there is a substantial memory overhead for managing the data structures: examples are
>     * using separate (hash) tables for the three different types of card containers
>     * there is significant unnecessary preallocation of memory for some of the card set containers
>     * Containers store redundant information
> 
> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
> 
> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
> 
> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
> 
> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
> 
> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
> 
> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
> 
> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
> 
> This initial fully working change can be roughly described with the following properties:
> 
> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
> 
> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
> 
> * there are now four different container types and one meta-container type. These four actual containers are:
>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
> 
> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
> 
> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
> 
> Testing: tier1-8 many times, manual and automated perf testing

Just a few comments to get this going.

src/hotspot/share/gc/g1/g1CardSet.hpp line 182:

> 180:    * X...XXX10 bitmap
> 181:    * X...XXX11 howl (64 bit)
> 182:    */

Use `//` comments as we do in the rest of the file.

src/hotspot/share/gc/g1/g1CardSet.hpp line 259:

> 257: 
> 258:   template <class FOUND>
> 259:   void iterate_cards_or_ranges_in_container(CardSetPtr const card_set, FOUND& found);

I think we should come up with a more descriptive name than `FOUND` here.

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 69:

> 67:   G1CardSetInlinePtr() : _value_addr(nullptr), _value((CardSetPtr)G1CardSet::CardSetInlinePtr) { }
> 68: 
> 69:   G1CardSetInlinePtr(uint const card_idx, uint const bits_per_card);

Unused, can be removed, right?

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 86:

> 84:   void iterate(FOUND& found, uint const bits_per_card);
> 85: 
> 86:   uint card_at(uint const idx, uint const bits_per_card) {

Also unused I believe.

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 176:

> 174:   size_t max_entries() const { return _size; }
> 175: 
> 176:   uint card_at(uint const idx) {

Unused.

src/hotspot/share/gc/g1/g1CardSetFreeMemoryTask.cpp line 185:

> 183:     if (!is_enqueued()) {
> 184:       schedule(reschedule_delay_ms());
> 185:     }

Instead of using enqueue I think it might be better to to something similar to what `G1UncommitRegionTask` does, and keep a state for this task that can be checked before scheduling during a GC. Then this code can always reschedule when needed. 

So basically, never schedule a task that is already scheduled or running.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2584:

> 2582:   if (!_free_card_set_memory_task->is_enqueued()) {
> 2583:     _service_thread->schedule_task(_free_card_set_memory_task, 0);
> 2584:   }

I would suggest to move the scheduling decision into `notify_new_stats` or make these calls in a helper so that there is only a single call in this function.

src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp line 111:

> 109:     MergeRSHowlFull,
> 110:     MergeRSDirtyCards,
> 111:     MergeRSContainersLast

Maybe use Sentinel to match the above enum.
Suggestion:

    MergeRSContainersSentinel

src/hotspot/share/gc/g1/g1RemSet.cpp line 1206:

> 1204:         _region_base_idx = (size_t)region_idx << HeapRegion::LogCardsPerRegion;
> 1205:         _stats.inc_card_set_merged(tag);
> 1206:         return true;

Not entierly sure where to put this comment, but this closure is used both as a heap-region closure and as a closure for container-iterations. I think this should be documented somehow. Maybe both above this closure and maybe also list what closures are used for container-iteration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4116

From github.com+4146708+a74nh at openjdk.java.net  Wed May 26 10:08:21 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Wed, 26 May 2021 10:08:21 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
Message-ID: <pcLInjEqQwlL6V--l54mi8XzKMxMW3J3Jdwhq7LKjJs=.7d272c7f-153b-40f2-baa4-8392aaec2377@github.com>

On Fri, 21 May 2021 11:07:14 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure pointer is stripped on macos
>   
>   Change-Id: Idcf5f08e87c1e1f5af1dc8f421f8c7efc3d9c4c2
>   CustomizedGitHooks: yes

> Why can't we just add the **assert** to the **frame()** constructor instead?

> Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?

I'll try both these see which is the better option (one probably counteracts the other).


> I don't think that's correct description of current PAC state on macos11
> if binary is of type arm64e then it has pac enabled and it works. (most of system binaries are already arm64e, also the kernel and kernel extensions are arm64e already)
> To be able to test your own arm64e binary one need to add to boot-args ( https://developer.apple.com/documentation/driverkit/debugging_and_testing_system_extensions?language=objc ) -arm64e_preview_abi, otherwise the kernel won't allow custom arm64e app to start.
> 
> But, there is one thing, the shared library cache is arm64e only ( check folder /System/Library/dyld), and all of few remaining dylibs ( check any in /usr/lib) is arm64e only ( plus x86_64). arm64 apps use arm64e libs.
> All of these arm64e libs use PAC and it works ( not disabled/NOP-ed), as a result we had a bug recently - https://bugs.openjdk.java.net/browse/JDK-8267235
> 
> jvm probably needs to sanitize any pointer coming from native system libs.

Much better description than I gave, thanks :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From simonis at openjdk.java.net  Wed May 26 10:45:26 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 26 May 2021 10:45:26 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v21]
In-Reply-To: <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
Message-ID: <w8W4JrmYlXLR2ebG6bDkN68zkVENnU9q91LatxtduCY=.175dfe9d-8895-4468-9cab-2138c4ee2846@github.com>

On Tue, 25 May 2021 05:23:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove AsyncLogWriter::flush() from os::shutdown().
>    
>    When jvm aborts, it won't invoke AsyncLogWriter::flush() and guarantee
>    not to hinder the aborting process.
>    
>    Run all unified logging tests in async mode.
>  - Biased to the thread which is taking buffer lock.

Hi David,

is my understanding right that you're now fine with this change except for the question about potentially loosing logs in the case of an abort?

You have rightly argued that we don't want to wait an undefined amount of  time while we're in the process of aborting. As a consequence, Xin has removed the call to `AsyncLogWriter::flush()` from `os::shutdown()`. I think that's a good compromise because aborting is a rare event and even if aborting the probability of loosing log messages is very low. Using async logging already comes with the risk of loosing log messages in the case where the reserved buffer for async logging is too small. That's the tradeoff all users of async logging will have to pay for better latency. I don't think that the ultra-low probability of loosing logs in the case of a crash makes any difference for the general usability of this feature.

You've specifically asked for Thomas' opinion on this topic but he's out of the office for the next two weeks and I don't think that his absence should further block the integration of this patch. We've discussed this PR for more than two month in more than 250 messages. The PR has 4 approvals by now and I think it is really time to finally ship it.

Please let us know if you have any additional, sever objections? Otherwise it would be great if you could approve it as well.

Thank you and best regards,
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From tschatzl at openjdk.java.net  Wed May 26 11:07:13 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 May 2021 11:07:13 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets
In-Reply-To: <z413Kwj8WvIX6uHeu8znszaLX1OBRCOVwrpDLo7rBHo=.f597dee6-e475-4d1f-824a-fddd4994f816@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
 <z413Kwj8WvIX6uHeu8znszaLX1OBRCOVwrpDLo7rBHo=.f597dee6-e475-4d1f-824a-fddd4994f816@github.com>
Message-ID: <2rCfqstgWkkA_IwFZgct7S9H9T6Ls6_9EL38Y06348c=.a6455702-50bf-434c-ac1f-a1f1b509a9cc@github.com>

On Wed, 26 May 2021 09:03:34 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
>> 
>>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
>> 
>> Over time many problems with performance and in particular memory usage have been observed:
>> 
>> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
>> 
>> * there is a substantial memory overhead for managing the data structures: examples are
>>     * using separate (hash) tables for the three different types of card containers
>>     * there is significant unnecessary preallocation of memory for some of the card set containers
>>     * Containers store redundant information
>> 
>> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
>> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
>> 
>> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
>> 
>> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
>> 
>> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
>> 
>> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
>> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
>> 
>> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
>> 
>> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
>> 
>> This initial fully working change can be roughly described with the following properties:
>> 
>> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
>> 
>> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
>> 
>> * there are now four different container types and one meta-container type. These four actual containers are:
>>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
>> 
>> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
>> 
>> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
>> 
>> Testing: tier1-8 many times, manual and automated perf testing
>
> src/hotspot/share/gc/g1/g1RemSet.cpp line 1206:
> 
>> 1204:         _region_base_idx = (size_t)region_idx << HeapRegion::LogCardsPerRegion;
>> 1205:         _stats.inc_card_set_merged(tag);
>> 1206:         return true;
> 
> Not entierly sure where to put this comment, but this closure is used both as a heap-region closure and as a closure for container-iterations. I think this should be documented somehow. Maybe both above this closure and maybe also list what closures are used for container-iteration.

There is already a small comment that reads

// Visitor for remembered sets, dropping entries onto the card table.

at the top of the class declaration. I'll expand on that.

These methods are called by the template magic (for expected devirtualization purposes), but maybe we should add "fake" interfaces for this purpose.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4116

From stefank at openjdk.java.net  Wed May 26 11:39:29 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 11:39:29 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails [v2]
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <hWpSBtjYTHZrm4Xfpr6dVfh2o9LOGrj0Rc42uR2aV_4=.f6606dde-9cfa-4af8-af11-615d708c8cc5@github.com>

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review kbarrett

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4163/files
  - new: https://git.openjdk.java.net/jdk/pull/4163/files/b2b3b649..71879fb6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4163&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4163&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4163/head:pull/4163

PR: https://git.openjdk.java.net/jdk/pull/4163

From david.holmes at oracle.com  Wed May 26 12:49:05 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 26 May 2021 22:49:05 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v21]
In-Reply-To: <w8W4JrmYlXLR2ebG6bDkN68zkVENnU9q91LatxtduCY=.175dfe9d-8895-4468-9cab-2138c4ee2846@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
 <w8W4JrmYlXLR2ebG6bDkN68zkVENnU9q91LatxtduCY=.175dfe9d-8895-4468-9cab-2138c4ee2846@github.com>
Message-ID: <06e0f61e-dc96-f3bd-48e3-92e8a7001493@oracle.com>

Hi Volker,

On 26/05/2021 8:45 pm, Volker Simonis wrote:
> On Tue, 25 May 2021 05:23:56 GMT, Xin Liu <xliu at openjdk.org> wrote:
> 
>>> This patch provides a buffer to store asynchrounous messages and flush them to
>>> underlying files periodically.
>>
>> Xin Liu has updated the pull request incrementally with two additional commits since the last revision:
>>
>>   - Remove AsyncLogWriter::flush() from os::shutdown().
>>     
>>     When jvm aborts, it won't invoke AsyncLogWriter::flush() and guarantee
>>     not to hinder the aborting process.
>>     
>>     Run all unified logging tests in async mode.
>>   - Biased to the thread which is taking buffer lock.
> 
> Hi David,
> 
> is my understanding right that you're now fine with this change except for the question about potentially loosing logs in the case of an abort?

I was concerned about making the thread wait() when trying to abort, but 
Xin has changed that now as he now agrees there is an issue there. So 
that does mean we might lose some log entries on abort but I hadn't 
flagged that as an issue (but did someone else earlier?).

I was also checking on the exact role of the iosem and why the tests had 
failed - see my email earlier today on that. I'm not sure it is the best 
way to solve the problem but I'm okay with it.

> You have rightly argued that we don't want to wait an undefined amount of  time while we're in the process of aborting. As a consequence, Xin has removed the call to `AsyncLogWriter::flush()` from `os::shutdown()`. I think that's a good compromise because aborting is a rare event and even if aborting the probability of loosing log messages is very low. Using async logging already comes with the risk of loosing log messages in the case where the reserved buffer for async logging is too small. That's the tradeoff all users of async logging will have to pay for better latency. I don't think that the ultra-low probability of loosing logs in the case of a crash makes any difference for the general usability of this feature.
> 
> You've specifically asked for Thomas' opinion on this topic but he's out of the office for the next two weeks and I don't think that his absence should further block the integration of this patch. We've discussed this PR for more than two month in more than 250 messages. The PR has 4 approvals by now and I think it is really time to finally ship it.

Except that those approvals are not for the current updated version of 
the code, so I would expect to see re-reviews by as many of those who 
already reviewed it as possible. I really don't like it when we have a 
non-trivial feature like this and we don't get a consensus amongst 
reviewers on the final product. It is unfortunate that Thomas is away, 
as I would hate for him to come back and find this had gone in 
unexpected directions. I would really like to hear that the other 
reviewers are okay with how this code ended up.

Thanks,
David
-----

> Please let us know if you have any additional, sever objections? Otherwise it would be great if you could approve it as well.


> Thank you and best regards,
> Volker
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From kbarrett at openjdk.java.net  Wed May 26 13:44:15 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 May 2021 13:44:15 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails [v2]
In-Reply-To: <hWpSBtjYTHZrm4Xfpr6dVfh2o9LOGrj0Rc42uR2aV_4=.f6606dde-9cfa-4af8-af11-615d708c8cc5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
 <hWpSBtjYTHZrm4Xfpr6dVfh2o9LOGrj0Rc42uR2aV_4=.f6606dde-9cfa-4af8-af11-615d708c8cc5@github.com>
Message-ID: <3T_YRz2dr9iTsaoXk0dsu5Cn--Lb2M4HHpDoomyRymQ=.58877c56-1cae-4508-8928-6e5b149b1104@github.com>

On Wed, 26 May 2021 11:39:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4163

From tschatzl at openjdk.java.net  Wed May 26 14:35:17 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 May 2021 14:35:17 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v2]
In-Reply-To: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
Message-ID: <SoOifX2KG270pCeDiAaoSAAhW0prZYBXwBuRythiT5Y=.9482c72f-9e71-4d63-9b72-3d9f4af51019@github.com>

> Hi all,
> 
>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
> 
>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
> 
> Over time many problems with performance and in particular memory usage have been observed:
> 
> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
> 
> * there is a substantial memory overhead for managing the data structures: examples are
>     * using separate (hash) tables for the three different types of card containers
>     * there is significant unnecessary preallocation of memory for some of the card set containers
>     * Containers store redundant information
> 
> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
> 
> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
> 
> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
> 
> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
> 
> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
> 
> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
> 
> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
> 
> This initial fully working change can be roughly described with the following properties:
> 
> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
> 
> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
> 
> * there are now four different container types and one meta-container type. These four actual containers are:
>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
> 
> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
> 
> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
> 
> Testing: tier1-8 many times, manual and automated perf testing

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - Remove prefetching of log buffers
 - iwalulya, sjohanss review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4116/files
  - new: https://git.openjdk.java.net/jdk/pull/4116/files/a5888523..01ecd285

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=00-01

  Stats: 198 lines in 16 files changed: 39 ins; 115 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4116/head:pull/4116

PR: https://git.openjdk.java.net/jdk/pull/4116

From kbarrett at openjdk.java.net  Wed May 26 14:38:15 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 May 2021 14:38:15 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v5]
In-Reply-To: <c-OaKR1PFHIGfLRVAIG-RHC5EnozbxTHzTMq_5TRl_g=.140285a5-9230-4931-9679-8945670749d8@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <c-OaKR1PFHIGfLRVAIG-RHC5EnozbxTHzTMq_5TRl_g=.140285a5-9230-4931-9679-8945670749d8@github.com>
Message-ID: <GljqMekBQKJKTwU-8ELrwL-oKyRgC6y3S_vI62IlP1U=.8af96aac-9fbc-42ca-b091-78280473188b@github.com>

On Wed, 26 May 2021 06:38:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review dholmes

doc/hotspot-style.md line 142:

> 140: 
> 141: * All .inline.hpp files should include their corresponding .hpp file
> 142: as the first include line. Externally used declarations should be put

I think by "Externally used declarations" you mean "declarations needed by other headers"?  Maybe say it that way, or some other wording?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From gziemski at openjdk.java.net  Wed May 26 15:53:15 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 26 May 2021 15:53:15 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <pcLInjEqQwlL6V--l54mi8XzKMxMW3J3Jdwhq7LKjJs=.7d272c7f-153b-40f2-baa4-8392aaec2377@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <pcLInjEqQwlL6V--l54mi8XzKMxMW3J3Jdwhq7LKjJs=.7d272c7f-153b-40f2-baa4-8392aaec2377@github.com>
Message-ID: <TIbLsvpMP83UKeBC6ZTTyVThvITg0XesHsRZ8kbzSGU=.82702aa2-ae9f-417a-8889-394ad141d2f9@github.com>

On Wed, 26 May 2021 10:05:36 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> > Why can't we just add the **assert** to the **frame()** constructor instead?
> 
> > Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?
> 
> I'll try both these see which is the better option (one probably counteracts the other).
> 
> > I don't think that's correct description of current PAC state on macos11
> > if binary is of type arm64e then it has pac enabled and it works. (most of system binaries are already arm64e, also the kernel and kernel extensions are arm64e already)
> > To be able to test your own arm64e binary one need to add to boot-args ( https://developer.apple.com/documentation/driverkit/debugging_and_testing_system_extensions?language=objc ) -arm64e_preview_abi, otherwise the kernel won't allow custom arm64e app to start.
> > But, there is one thing, the shared library cache is arm64e only ( check folder /System/Library/dyld), and all of few remaining dylibs ( check any in /usr/lib) is arm64e only ( plus x86_64). arm64 apps use arm64e libs.
> > All of these arm64e libs use PAC and it works ( not disabled/NOP-ed), as a result we had a bug recently - https://bugs.openjdk.java.net/browse/JDK-8267235
> > jvm probably needs to sanitize any pointer coming from native system libs.
> 
> Much better description than I gave, thanks :)

Thank you from me too. Also thank you for the **-arm64e_preview_abi** boot argument link.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From tschatzl at openjdk.java.net  Wed May 26 16:15:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 May 2021 16:15:08 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v3]
In-Reply-To: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
Message-ID: <zJc-t62PpdVrwPE99ggQByiS16jkHQVNTleJED_hY_I=.eb7a63fa-35f4-46fd-a30d-ca9d0f8acf55@github.com>

> Hi all,
> 
>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
> 
>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
> 
> Over time many problems with performance and in particular memory usage have been observed:
> 
> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
> 
> * there is a substantial memory overhead for managing the data structures: examples are
>     * using separate (hash) tables for the three different types of card containers
>     * there is significant unnecessary preallocation of memory for some of the card set containers
>     * Containers store redundant information
> 
> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
> 
> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
> 
> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
> 
> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
> 
> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
> 
> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
> 
> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
> 
> This initial fully working change can be roughly described with the following properties:
> 
> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
> 
> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
> 
> * there are now four different container types and one meta-container type. These four actual containers are:
>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
> 
> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
> 
> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
> 
> Testing: tier1-8 many times, manual and automated perf testing

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Rename FOUND

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4116/files
  - new: https://git.openjdk.java.net/jdk/pull/4116/files/01ecd285..c1b83e02

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=01-02

  Stats: 67 lines in 5 files changed: 31 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4116/head:pull/4116

PR: https://git.openjdk.java.net/jdk/pull/4116

From coleenp at openjdk.java.net  Wed May 26 17:15:14 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 26 May 2021 17:15:14 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <h_kb477-bO0tB2eftLaL63bzxFpsG2DmQ2e4t902qtY=.9be30237-e896-499d-84e9-1d10d8f3c488@github.com>

On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

I'm sorry for the delay and for introducing the bug.  I'm hopefully back in the frame of mind I was in when making the change.  See if what I said makes sense.

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1861:

> 1859:   // Save fields from the old_cp.
> 1860:   merge_cp->copy_fields(old_cp(), true /* skip_version */);
> 1861:   scratch_cp->copy_fields(old_cp(), true /* skip_version */);

Rather than calling copy_fields, maybe this should revert this:
-  if (old_cp->has_dynamic_constant()) {
-    merge_cp->set_has_dynamic_constant();
-    scratch_cp->set_has_dynamic_constant();
-  }

And then the merge_cp->copy_fields(scratch_cp); ?

The merged_cp should look like the scratch_cp (with version number and generic signature, etc) until after verification and then I guess it should look like the old_cp at the end in redefine_single_class().

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4412:

> 4410:   the_class->constants()->set_major_version(scratch_class->constants()->major_version());
> 4411:   scratch_class->constants()->set_major_version(old_major_version);
> 4412: 

This looks correct. copy_fields doesn't swap the versions, and I think that's what we want to do.
The source_name_index should match the scratch_class which is above, and the generic_signature_index is checked that it matches, and the one in the scratch constant pool should be adjusted to match the merged constant pool.  So I think that's ok.

test/hotspot/jtreg/runtime/ConstantPool/ClassVersion/ClassVersionAfterRedefine.java line 1:

> 1: /*

Can you put this test in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses directory?
All the tests do redefinition differently.  There is a library RedefineClassHelper that you might be able to use and not have to deal with starting the agent.

@ compile TestClassXXX.jasm   // this is the old one
then in the test read all of TestClassNew.jasm bytecodes, and s/New/XXX/ and use
RedefineClassHelper.redefine(TestClassXXX.class, newBytes);

See RedefineRunningMethods.java in that directory for an example.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4149

From stefank at openjdk.java.net  Wed May 26 18:00:54 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 18:00:54 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review kbarrett

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/0cf6257d..340bcf49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=04-05

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Wed May 26 18:01:24 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 18:01:24 GMT
Subject: RFR: 8267611: Print more info when pointer_delta assert fails [v2]
In-Reply-To: <hWpSBtjYTHZrm4Xfpr6dVfh2o9LOGrj0Rc42uR2aV_4=.f6606dde-9cfa-4af8-af11-615d708c8cc5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
 <hWpSBtjYTHZrm4Xfpr6dVfh2o9LOGrj0Rc42uR2aV_4=.f6606dde-9cfa-4af8-af11-615d708c8cc5@github.com>
Message-ID: <1EYzg6uo4ZdowFIX7zSXyDO08YiWJ5vfXgJfzq3NRRU=.f41aa387-31f8-4513-b74a-afcc42482712@github.com>

On Wed, 26 May 2021 11:39:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4163

From stefank at openjdk.java.net  Wed May 26 18:01:26 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 18:01:26 GMT
Subject: Integrated: 8267611: Print more info when pointer_delta assert fails
In-Reply-To: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
References: <EwTdktVNFYXJf3SD-AfzymJ16tia9lbjcRRoT2aU0pI=.65284c2a-5016-4a85-9072-3e270dddf7a5@github.com>
Message-ID: <NIUie_-FeURSNw5OUBxxqnGtutFCWYmRtscdG2AOu0Q=.a07be955-41db-49e7-8f93-e7e9dae79355@github.com>

On Mon, 24 May 2021 11:11:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We've seen a few new failures with the new pointer_delta assert. It would be nice if the assert printed the 'left' and 'right' pointer values.

This pull request has now been integrated.

Changeset: de91643b
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de91643bfa80ae7cc2d228f882b2de3d8af543c8
Stats:     11 lines in 1 file changed: 5 ins; 5 del; 1 mod

8267611: Print more info when pointer_delta assert fails

Reviewed-by: dholmes, jiefu, tschatzl, kbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/4163

From pchilanomate at openjdk.java.net  Wed May 26 18:07:16 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 26 May 2021 18:07:16 GMT
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes [v2]
In-Reply-To: <Vlg6EpsZj7VNzjxfLXoA-mwseSNfctrdUPfqFoX98Vg=.6b8be221-b1dd-476b-8596-45c0d4d5fcc6@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
 <Vlg6EpsZj7VNzjxfLXoA-mwseSNfctrdUPfqFoX98Vg=.6b8be221-b1dd-476b-8596-45c0d4d5fcc6@github.com>
Message-ID: <XLE9o1X0Q5Jom6URih8n3RrX9mqPbNLK3wyYWbNK1B8=.502d62ef-fba3-4d72-a4db-a8f6de4c8973@github.com>

On Wed, 26 May 2021 01:53:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
>> Tested with tier 2-3 and tier1 in progress.
>> Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert that the thread is terminated before taking Heap_lock

Looks good to me!

Thanks,
Patricio

-------------

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4184

From xliu at openjdk.java.net  Wed May 26 18:15:25 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 26 May 2021 18:15:25 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
In-Reply-To: <d74e33e3-a072-4ed7-0c50-d59481caeb99@oracle.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <d74e33e3-a072-4ed7-0c50-d59481caeb99@oracle.com>
Message-ID: <HKDJVDRvYpeDbdNIFzvlez4gVlPb8URQUiyZKHWCUuY=.9c918348-8b99-4409-a141-4fb23073154d@github.com>

On Wed, 26 May 2021 05:41:52 GMT, David Holmes <david.holmes at oracle.com> wrote:

> So again prior to this the real problem was a race between final logging
output and VM termination, that could result in either crashes or lost
logs messages, which in turn could cause test failures.

For `LogConfiguration::disable_outputs`, it's not just for JVM termination. 
When you send a dcmd `VM.log disable` to a running JVM, it also invokes it. 
 
That bug caused JVM may crashes AND lost messages. 
If `flush()` can't guarantee all dequeued messages have been written before returning, we may end up using broken pointers. 


void LogConfiguration::disable_outputs() {
  size_t idx = _n_outputs;

  // Remove all outputs from all tagsets.
  for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
    ts->disable_outputs();
  }

  // Handle jcmd VM.log disable
  // ts->disable_outputs() above has deleted output_list with RCU synchronization.
  // Therefore, no new logging entry can enter AsyncLog buffer for the time being.
  // flush pending entries before LogOutput instances die.
  AsyncLogWriter::flush();

  while (idx > 0) {
    LogOutput* out = _outputs[--idx];
    // Delete the output unless stdout or stderr (idx 0 or 1)
    if (idx > 1) {
      delete_output(idx);
    } else {
      out->set_config_string("all=off");
    }
  }
}

Those LogOutput instances are destroyed right after flush(). 
Each AsyncLogMessage instance contains a reference of LogFileOutput. LogWriter thread may use those deleted pointers! 
that's the root cause you saw that intermittent crashes. 

```c++
e->output()->write_blocking(e->decorations(), msg);


> At one stage I believe you had intended to terminate the async writer
thread, and that would have fixed the problem as well - assuming you
handled the termination properly.

Yes, I used to have a termination protocol. It was also very complex because it must be MT-safe, no message lost and no concurrency with synchronous logging. Thomas disliked that and suggested me to remove the termination protocol(100+ line).

AsyncLogWriter::terminate() was placed before `LogConfiguration::finalize()`, therefore, it hid the problem in JVM termination. 
It can't help for the dcmd situation, which we still need strong `flush()`.The second use of strong `flush()` is for gtest. Without it, it's impossible to have a reliable way to check the results of async logging.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From simonis at openjdk.java.net  Wed May 26 19:06:25 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 26 May 2021 19:06:25 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v21]
In-Reply-To: <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <Fq1sTQYI6YTvQmuq-_AEoNXqZI4Q6HI0AdGn_SRqCqM=.9d84edf8-7e65-4d13-b8ca-fe56884692d3@github.com>
Message-ID: <YcQS1wtfMgBn41w0QIQEUtxX8_Pb7_RifEi3t_OLs_I=.7c469f27-03ae-4c9e-b40b-eef18cc04569@github.com>

On Tue, 25 May 2021 05:23:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove AsyncLogWriter::flush() from os::shutdown().
>    
>    When jvm aborts, it won't invoke AsyncLogWriter::flush() and guarantee
>    not to hinder the aborting process.
>    
>    Run all unified logging tests in async mode.
>  - Biased to the thread which is taking buffer lock.

I'm fine with the latest version of this patch.

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From coleenp at openjdk.java.net  Wed May 26 19:11:14 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 26 May 2021 19:11:14 GMT
Subject: RFR: 8267653: Remove Mutex::_safepoint_check_sometimes [v2]
In-Reply-To: <Vlg6EpsZj7VNzjxfLXoA-mwseSNfctrdUPfqFoX98Vg=.6b8be221-b1dd-476b-8596-45c0d4d5fcc6@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
 <Vlg6EpsZj7VNzjxfLXoA-mwseSNfctrdUPfqFoX98Vg=.6b8be221-b1dd-476b-8596-45c0d4d5fcc6@github.com>
Message-ID: <_CnhaU9EWmjSpv7rDdmykhpe41VDnYxot4hY0wABOBA=.c8f5e256-22f7-4b71-a961-b42a200e797f@github.com>

On Wed, 26 May 2021 01:53:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
>> Tested with tier 2-3 and tier1 in progress.
>> Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert that the thread is terminated before taking Heap_lock

Thanks Patricio and David!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4184

From coleenp at openjdk.java.net  Wed May 26 19:11:15 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 26 May 2021 19:11:15 GMT
Subject: Integrated: 8267653: Remove Mutex::_safepoint_check_sometimes
In-Reply-To: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
References: <OpIHO8GcqBWsONZ6MNwlQzaQ6Z4dfekskdRrmUhT8M8=.853bdb38-9966-42fc-8d38-4147836d93e6@github.com>
Message-ID: <GXpw72eJxw8mbJt4ULQ3b_ZfRkwftACZ2R-OJp7Rq14=.823cb645-61b4-4a73-aca0-1de780cf2c96@github.com>

On Tue, 25 May 2021 13:20:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
> Tested with tier 2-3 and tier1 in progress.
> Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).

This pull request has now been integrated.

Changeset: c59484e7
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c59484e71517ea9fea7df7b0344b633495f8fd81
Stats:     26 lines in 5 files changed: 4 ins; 19 del; 3 mod

8267653: Remove Mutex::_safepoint_check_sometimes

Reviewed-by: dholmes, pchilanomate

-------------

PR: https://git.openjdk.java.net/jdk/pull/4184

From gziemski at openjdk.java.net  Wed May 26 20:59:06 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 26 May 2021 20:59:06 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
Message-ID: <SFKaCleiD5B58Ll-r4tyejaYSOYf7ebDuayGknVYTr8=.dac52aa5-dd5e-4414-955a-b8ce6c3db8ed@github.com>

On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
>> 
>> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
>> 
>> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
>> 
>> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
>> 
>> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
>> 
>> Results from Linux:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
>> ==============================
>> TEST SUCCESS
>> 
>> 
>> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
>> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
>> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
>> 
>> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
>> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> Test results: passed: 1
>> 
>> 
>> Results from Windows 10:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
>> ==============================
>> TEST SUCCESS
>> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
>> 
>> 
>> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
>> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
>> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
>> 
>> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
>> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> Test results: passed: 1
>
> Maxim Kartashev 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:
> 
>   8195129: System.load() fails to load from unicode paths

I tried verifying the test on **macOS** by running:

`jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`

and I get:

`TEST RESULT: Error. Use -nativepath to specify the location of native code`

I looked at the test and thought it was handling loading the native lib on its own, without the test needing to set  **nativepath** explicitly.  What am I doing wrong?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From xliu at openjdk.java.net  Wed May 26 22:53:09 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 26 May 2021 22:53:09 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <I30YzZUiBDvCkVQgOUUBVFg7dG0HAZSjyXEmVfRXtN0=.2d7330b4-3a6c-49af-b926-867796ee0355@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

hi, @iklam 
Could you take a look at this. 

thanks, 
--lx

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From kbarrett at openjdk.java.net  Wed May 26 23:06:05 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 May 2021 23:06:05 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6]
In-Reply-To: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
Message-ID: <OPTS0x5KcDzroluKpqAFeuFg0km3_z0BrJuEPgDSPyg=.e2006f2c-07e0-42fc-a685-79dea3d0f5ac@github.com>

On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From iklam at openjdk.java.net  Wed May 26 23:39:04 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 26 May 2021 23:39:04 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <VkxLYnJ_2KPppIq4XlM0Z3iY-av6SbY5qxZfvqKFr6o=.5577a4e4-54ef-4459-a4e7-32045f37bb53@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

If I understand correctly, the design of `LinkedList` provides an abstract base type `LinkedList<T>`, so that you can use


LinkedList<MyType>* list = .....;
MyType v = ....;
bool exists = list->find(v);


If you remove  the`virtual LinkedList<T>::find() = 0;` declaration, the above code will not work anymore.

Your patch can compile because `find` is currently used only once here, where the implementation type is known at compile time:


bool MemBaseline::aggregate_virtual_memory_allocation_sites() {
  SortedLinkedList<VirtualMemoryAllocationSite, compare_allocation_site> allocation_sites;
  ...
    site = allocation_sites.find(tmp);


However, this will not work in the future when we have other use of `find` where the exact implementation type is not known.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From xliu at openjdk.java.net  Thu May 27 00:18:07 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 00:18:07 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <MKYfjCsl6ZoXRbsvBLTbAsPVtGp3j99NlPjR7TTMj-I=.ee67b6c5-ba73-4c61-964a-d2f209a9b417@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

hi, Ioi, 

Thank you for reviewing it. Yes, what you said is 100% correct. 

Look, this is the very problem of this LinkedList. You pay for what you don't use. It's very not c++.
To support non-existence use case, C++ has to instantiate template member functions and calll them via vtable.   
(That's how Java works because Java has dynamic solution for devirtualization.)

LinkedList is a ADL container. What's the point to support class hierarchy for it? Why do we need late binding for find()?


SortedLinkedList<VirtualMemoryAllocationSite, compare_allocation_site> allocation_sites;
...
site = allocation_sites.find(tmp);

This is real code.

I didn't overthrow the design. I just would like to free up from this equals(). I actually don't use find at all.
https://github.com/openjdk/jdk/pull/3135/files#diff-31de33d2853a803965fd4381172f11904a44f42a125b02caec206f72c94f89d6R103

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From david.holmes at oracle.com  Thu May 27 04:14:19 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 27 May 2021 14:14:19 +1000
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <SFKaCleiD5B58Ll-r4tyejaYSOYf7ebDuayGknVYTr8=.dac52aa5-dd5e-4414-955a-b8ce6c3db8ed@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
 <SFKaCleiD5B58Ll-r4tyejaYSOYf7ebDuayGknVYTr8=.dac52aa5-dd5e-4414-955a-b8ce6c3db8ed@github.com>
Message-ID: <de5c67e5-0fe1-e88b-78c1-c186aceab68f@oracle.com>

On 27/05/2021 6:59 am, Gerard Ziemski wrote:
> On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:
> I tried verifying the test on **macOS** by running:
> 
> `jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`
> 
> and I get:
> 
> `TEST RESULT: Error. Use -nativepath to specify the location of native code`
> 
> I looked at the test and thought it was handling loading the native lib on its own, without the test needing to set  **nativepath** explicitly.  What am I doing wrong?

You always have to set nativepath explicitly for jtreg. The test then 
reads the property that jtreg defines using the value of -nativepath:

String testNativePath = 
LoadLibraryUnicodeTest.getSystemProperty("test.nativepath");

Cheers,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4169
> 

From chris at sageembedded.com  Thu May 27 04:37:28 2021
From: chris at sageembedded.com (Chris Cole)
Date: Wed, 26 May 2021 21:37:28 -0700
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCV9WNpGQ2XG_bmi0iEU1YOhB71BHRkWbLv=4mDtgoLhwA@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
 <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
 <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>
 <c5427513-d770-4cad-182e-0c29f66e62b7@bell-sw.com>
 <CABQ9BCV9WNpGQ2XG_bmi0iEU1YOhB71BHRkWbLv=4mDtgoLhwA@mail.gmail.com>
Message-ID: <CABQ9BCXaTUjaqAghQ1Yag3BpcrL=MzmNQjjCEdKsY720ECz40A@mail.gmail.com>

Hi Boris,

Here is an updated test case at
https://github.com/chrishcole/jdk/blob/arm32_c1_monitor_bug/test/hotspot/jtreg/compiler/c1/Test8267042.java.

Thanks,
Chris

On Mon, May 24, 2021 at 11:56 AM Chris Cole <chris at sageembedded.com> wrote:
>
> Hi Boris,
>
> On Sun, May 23, 2021 at 1:38 PM Boris Ulasevich
> <boris.ulasevich at bell-sw.com> wrote:
> >
> > Hi Chris,
> >
> > I checked that the fix works fine and does not bring any regression.
> > Let me create pull request and sponsor the change.
> > Here is the fix and reproducer I prepared for review:
> > https://github.com/openjdk/jdk/compare/master...bulasevich:jdk-8267042-arm32-c1-lock-01
>
> Sounds great. Looks good to me.
>
> > (I think it is worth simplifying the MonitorBugTest)
>
> Yes, I agree. If you want I could try and simplify this, but won't
> have time to work on this until tomorrow.
>
> Thanks,
> Chris

From chris at sageembedded.com  Thu May 27 04:42:41 2021
From: chris at sageembedded.com (Chris Cole)
Date: Wed, 26 May 2021 21:42:41 -0700
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCXaTUjaqAghQ1Yag3BpcrL=MzmNQjjCEdKsY720ECz40A@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
 <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
 <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>
 <c5427513-d770-4cad-182e-0c29f66e62b7@bell-sw.com>
 <CABQ9BCV9WNpGQ2XG_bmi0iEU1YOhB71BHRkWbLv=4mDtgoLhwA@mail.gmail.com>
 <CABQ9BCXaTUjaqAghQ1Yag3BpcrL=MzmNQjjCEdKsY720ECz40A@mail.gmail.com>
Message-ID: <CABQ9BCXPqvQ12NJVPn+4-zrFd3=kYRxYDX3577WbQrdOYuFc2g@mail.gmail.com>

Hi Boris,

Not sure if the previous link works. If not, the updated test case is
inline below.

Thanks,
Chris

/*
 * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

package compiler.c1;

import java.io.IOException;
import java.io.InterruptedIOException;

/*
 * @test
 * @author Chris Cole
 * @bug 8267042
 * @summary missing displaced_header initialization causes hangup
 * @run main/othervm -XX:+TieredCompilation -XX:TieredStopAtLevel=1
 *                   -XX:-BackgroundCompilation -XX:CompileThreshold=1
 *                   -XX:CompileOnly=compiler.c1.Test8267042::write
 *                   compiler.c1.Test8267042
 */
public class Test8267042 {

    private static int DATA_SIZE = 4;

    private char buffer;
    private boolean empty = true;

    public static void main(String[] args) {
        Test8267042 test = new Test8267042();
        test.run();
    }

    private void run() {
        System.out.println("Starting test");

        Thread writeThread = new Thread(new Runnable() {
            @Override
            public void run() {
                char data[] = new char[DATA_SIZE];
                try {
                    write(data, 0, data.length);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        });
        writeThread.setDaemon(true);
        writeThread.start();

        Thread readThread = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    for (int i = 0; i < DATA_SIZE; i++) {
                        read();
                    }
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        });
        readThread.setDaemon(true);
        readThread.start();

        try {
            writeThread.join(5000);
            if (writeThread.isAlive()) {
                throw new InternalError("write thread deadlocked");
            }
            readThread.join(5000);
            if (readThread.isAlive()) {
                throw new InternalError("read thread deadlocked");
            }
        } catch (InterruptedException e) {
            throw new InternalError("unexpected InterrruptedException
while waiting to join threads", e);
        }
        System.out.println("Test passed");
    }

    synchronized void write(char data[], int offset, int length)
throws IOException {
        while (--length >= 0) {
            getZeroOnStack(offset);
            write(data[offset++]);
        }
    }

    synchronized void write(int c) throws IOException {
        while (!empty) {
            try {
                wait(1000);
            } catch (InterruptedException e) {
                throw new InterruptedIOException();
            }
        }
        buffer = (char) c;
        empty = false;
        notifyAll();
    }

    public synchronized int read() throws IOException {
        while (empty) {
            try {
                System.out.println("read() before wait");
                wait(1000);
                System.out.println("read() after wait");
            } catch (InterruptedException e) {
                throw new InterruptedIOException();
            }
        }
        int value = buffer;
        empty = true;
        notifyAll();
        return value;
    }

    private void getZeroOnStack(int offset) {
        int l1;
        int l2;
        int l3;
        int l4;
        int l5;
        int l6;
        int l7;
        int l8;
        int l9;
        int l10;
        int l11;
        int l12;
        int l13;
        int l14;
        int l15;
        int l16;

        l1 = 0;
        l2 = 0;
        l3 = 0;
        l4 = 0;
        l5 = 0;
        l6 = 0;
        l7 = 0;
        l8 = 0;
        l9 = 0;
        l10 = 0;
        l11 = 0;
        l12 = 0;
        l13 = 0;
        l14 = 0;
        l15 = 0;
        l16 = 0;
    }
}

On Wed, May 26, 2021 at 9:37 PM Chris Cole <chris at sageembedded.com> wrote:
>
> Hi Boris,
>
> Here is an updated test case at
> https://github.com/chrishcole/jdk/blob/arm32_c1_monitor_bug/test/hotspot/jtreg/compiler/c1/Test8267042.java.
>
> Thanks,
> Chris
>
> On Mon, May 24, 2021 at 11:56 AM Chris Cole <chris at sageembedded.com> wrote:
> >
> > Hi Boris,
> >
> > On Sun, May 23, 2021 at 1:38 PM Boris Ulasevich
> > <boris.ulasevich at bell-sw.com> wrote:
> > >
> > > Hi Chris,
> > >
> > > I checked that the fix works fine and does not bring any regression.
> > > Let me create pull request and sponsor the change.
> > > Here is the fix and reproducer I prepared for review:
> > > https://github.com/openjdk/jdk/compare/master...bulasevich:jdk-8267042-arm32-c1-lock-01
> >
> > Sounds great. Looks good to me.
> >
> > > (I think it is worth simplifying the MonitorBugTest)
> >
> > Yes, I agree. If you want I could try and simplify this, but won't
> > have time to work on this until tomorrow.
> >
> > Thanks,
> > Chris

From dholmes at openjdk.java.net  Thu May 27 05:08:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 05:08:07 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
Message-ID: <rCQB5gq6rwzV1_kU52ysU2yFlznwpK7_nwnQ4Q12Z0U=.9dc13ea0-9b38-4aa7-b095-07a5f3dac40b@github.com>

On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
>> 
>> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
>> 
>> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
>> 
>> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
>> 
>> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
>> 
>> Results from Linux:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
>> ==============================
>> TEST SUCCESS
>> 
>> 
>> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
>> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
>> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
>> 
>> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
>> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> Test results: passed: 1
>> 
>> 
>> Results from Windows 10:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
>> ==============================
>> TEST SUCCESS
>> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
>> 
>> 
>> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
>> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
>> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
>> 
>> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
>> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> Test results: passed: 1
>
> Maxim Kartashev 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:
> 
>   8195129: System.load() fails to load from unicode paths

Hi Maxim,

Please don't force-push changes once you have opened a PR and review has commenced as it messes up the history and comments. Just push each commit directly. The final integration will squash everything into one clean commit.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From dholmes at openjdk.java.net  Thu May 27 05:28:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 05:28:06 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
Message-ID: <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>

On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
>> 
>> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
>> 
>> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
>> 
>> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
>> 
>> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
>> 
>> Results from Linux:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
>> ==============================
>> TEST SUCCESS
>> 
>> 
>> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
>> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
>> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
>> 
>> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
>> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> Test results: passed: 1
>> 
>> 
>> Results from Windows 10:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
>> ==============================
>> TEST SUCCESS
>> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
>> 
>> 
>> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
>> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
>> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
>> 
>> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
>> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> Test results: passed: 1
>
> Maxim Kartashev 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:
> 
>   8195129: System.load() fails to load from unicode paths

Hi Maxim,

Overall this seems okay. I've focused mainly on the hotspot parts, including the test.

A few minor changes requested. I do have some concerns about the impact on startup though and the efficiency of the conversion routines.

Thanks,
David

src/hotspot/os/windows/os_windows.cpp line 1462:

> 1460:   const int flag_source_str_is_null_terminated = -1;
> 1461:   const int flag_estimate_chars_count = 0;
> 1462:   int utf16_chars_count_estimated = MultiByteToWideChar(source_encoding,

Your local naming style is somewhat excessive. You could just comment the values of the flags when you pass them eg:

MultiByteToWideChar(source_encoding,
                                    MB_ERR_INVALID_CHARS,
                                   source_str,
                                   -1, //source is null-terminated
                                  NULL, // no output buffer
                                  0); // calculate required buffer size

Or you could just add a comment before the call:

// Perform a dummy conversion so that we can get the required size of the buffer to
// allocate. The source is null-terminated.

Trying to document parameter semantics by variable naming doesn't work in my opinion - at some point if you want to know you have to RTFM for the API.

And utf16_len is perfectly adequate for the returned size.

src/hotspot/os/windows/os_windows.cpp line 1541:

> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) {
> 1540:   LPWSTR utf16_name = NULL;
> 1541:   errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name);

Do you have any figures on the cost of this additional conversion in relation to startup time?

I'm already concerned to see that we have to perform each conversion twice via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to actually get the characters! This seems potentially very inefficient.

test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java line 48:

> 46:         } else {
> 47:             throw new Error("Unsupported OS");
> 48:         }

Please use the test library function `Platform.sharedLibraryExt()` to get the library file extension.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4169

From david.holmes at oracle.com  Thu May 27 05:34:06 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 27 May 2021 15:34:06 +1000
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
In-Reply-To: <HKDJVDRvYpeDbdNIFzvlez4gVlPb8URQUiyZKHWCUuY=.9c918348-8b99-4409-a141-4fb23073154d@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <d74e33e3-a072-4ed7-0c50-d59481caeb99@oracle.com>
 <HKDJVDRvYpeDbdNIFzvlez4gVlPb8URQUiyZKHWCUuY=.9c918348-8b99-4409-a141-4fb23073154d@github.com>
Message-ID: <0cad407e-a515-3bf3-af3a-b9cac84694ed@oracle.com>

Hi Xin,

On 27/05/2021 4:15 am, Xin Liu wrote:
> On Wed, 26 May 2021 05:41:52 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> So again prior to this the real problem was a race between final logging
> output and VM termination, that could result in either crashes or lost
> logs messages, which in turn could cause test failures.
> 
> For `LogConfiguration::disable_outputs`, it's not just for JVM termination.
> When you send a dcmd `VM.log disable` to a running JVM, it also invokes it.

Thanks for highlighting that - yes that does make things additionally 
complicated. So this one mechanism is addressing both cases and so 
avoids the need for the additional termination protocol.

Thanks for bearing with me on this.

David
-----

> That bug caused JVM may crashes AND lost messages.
> If `flush()` can't guarantee all dequeued messages have been written before returning, we may end up using broken pointers.
> 
> 
> void LogConfiguration::disable_outputs() {
>    size_t idx = _n_outputs;
> 
>    // Remove all outputs from all tagsets.
>    for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
>      ts->disable_outputs();
>    }
> 
>    // Handle jcmd VM.log disable
>    // ts->disable_outputs() above has deleted output_list with RCU synchronization.
>    // Therefore, no new logging entry can enter AsyncLog buffer for the time being.
>    // flush pending entries before LogOutput instances die.
>    AsyncLogWriter::flush();
> 
>    while (idx > 0) {
>      LogOutput* out = _outputs[--idx];
>      // Delete the output unless stdout or stderr (idx 0 or 1)
>      if (idx > 1) {
>        delete_output(idx);
>      } else {
>        out->set_config_string("all=off");
>      }
>    }
> }
> 
> Those LogOutput instances are destroyed right after flush().
> Each AsyncLogMessage instance contains a reference of LogFileOutput. LogWriter thread may use those deleted pointers!
> that's the root cause you saw that intermittent crashes.
> 
> ```c++
> e->output()->write_blocking(e->decorations(), msg);
> 
> 
>> At one stage I believe you had intended to terminate the async writer
> thread, and that would have fixed the problem as well - assuming you
> handled the termination properly.
> 
> Yes, I used to have a termination protocol. It was also very complex because it must be MT-safe, no message lost and no concurrency with synchronous logging. Thomas disliked that and suggested me to remove the termination protocol(100+ line).
> 
> AsyncLogWriter::terminate() was placed before `LogConfiguration::finalize()`, therefore, it hid the problem in JVM termination.
> It can't help for the dcmd situation, which we still need strong `flush()`.The second use of strong `flush()` is for gtest. Without it, it's impossible to have a reliable way to check the results of async logging.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3135
> 

From dholmes at openjdk.java.net  Thu May 27 05:39:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 05:39:21 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v20]
In-Reply-To: <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <h7g3u-1ffqagNYcUNgyHPftXY9rfCOAGppdx7cP5Fvc=.452e72e0-82aa-4095-8e37-9e965caa0ddf@github.com>
Message-ID: <VhncJ-vQ66d86kDShKg2-jehbgXFtpr4H76gh01tr9s=.eb016d08-2860-458d-91dc-69559c20d78b@github.com>

On Mon, 24 May 2021 04:12:54 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flush() waits until all pending logging IO operations are done.
>   
>   This patch support all gtests in async mode.
>   make test TEST="gtest:all" TEST_OPTS='VM_OPTIONS=-Xlog:async'

Nothing further from me. Other than two typos my comments hadn't yet been sent for.

Thanks,
David

src/hotspot/share/logging/logAsyncWriter.cpp line 73:

> 71: 
> 72: // LogMessageBuffer consists of a multiple-part/multiple-line messsage.
> 73: // The lock here gurantees its integrity.

Typo: gurantees

src/hotspot/share/logging/logAsyncWriter.hpp line 117:

> 115: //
> 116: // Summary:
> 117: // Async Logging is working on the basis of singleton AsyncLogWriter, which manages an immediate buffer and a flushing thread.

typo: immediate -> intermediate

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From iklam at openjdk.java.net  Thu May 27 05:49:03 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 27 May 2021 05:49:03 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <ppCgbKBCxRj-b1rsJ7CbdyMRbmfaZy8nnCNTunDKLAI=.f58d3d7f-4ee7-4237-9198-19fd516825d2@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

By design, the `LinkedList` API supports polymorphism which is used by the existing code. For example: here we are moving from a `LinkedListImpl` into a `SortedLinkedList`.


void MemBaseline::malloc_sites_to_size_order() {
...
    SortedLinkedList<MallocSite, compare_malloc_size> tmp;
    tmp.move(&_malloc_sites); // _malloc_sites is a LinkedListImpl<...>


It will be odd if you change part of the API to non virtual just so that you can avoid implementing `equals`. I don't think this is the right thing to do.

Regarding the following comments in linkedlist.hpp:


  // Select member function 'bool U::equals(const U&) const' if 'U' is of class
  // type. This works because of the "Substitution Failure Is Not An Error"
  // (SFINAE) rule. Notice that this version of 'equal' will also be chosen for
  // class types which don't define a corresponding 'equals()' method (and will
  // result in a compilation error for them). It is not easily possible to
  // specialize this 'equal()' function exclusively for class types which define
  // the correct 'equals()' function because that function can be in a base
  // class, a dependent base class or have a compatible but slightly different
  // signature.
  template <class U>
  static bool equal(const U& a, const U& b, bool (U::*t)(const U&) const) {
    return a.equals(b);
  }


If you want to implement SFINAE to filter out element types that don't implement `equals`, maybe you can try this:

https://gist.github.com/fenbf/d2cd670704b82e2ce7fd

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From xliu at openjdk.java.net  Thu May 27 06:48:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 06:48:16 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v19]
In-Reply-To: <iBv5t0gJbcLwR1JtaEJZbwy92uIVOCJNoAjcCURxzfo=.0689a09c-aec7-44eb-9e24-988e081255d7@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <wO3zXn5n9d04w6mbI7qmsK-xBtCguUpEvETKuL8UbRo=.756feb93-fa17-499f-a7ac-982dac785a45@github.com>
 <zL6mGymDOZQud5fwyzMtxq8bUHZpHT5WHkfX7M7teCA=.d5d82a94-8897-49eb-b751-2714cb60a895@github.com>
 <yxrZ_BXQ38OvIZALUxf7qRG-HnOnRHAM0t4OshOLCqg=.6428d2f3-adad-4ed0-888b-c568af11f585@github.com>
 <iBv5t0gJbcLwR1JtaEJZbwy92uIVOCJNoAjcCURxzfo=.0689a09c-aec7-44eb-9e24-988e081255d7@github.com>
Message-ID: <AHFMV70_YvlwLpYUdZH9YeCy-plLdyXkS-f3YX5OX54=.53d98643-9a34-4b73-8b5d-70d1b0cbbfb5@github.com>

On Mon, 24 May 2021 08:55:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The value of _sem denotes the number of messages have been enqueued.  It's actually different from "the number of messages in _buffer".  When  _sem.wait() returns, it just **de**creases one.  however, _buffer.pop_all() pops all messages in queue at once.   The two numbers are not consistent all the time. 
>> 
>>> Maybe "_sem denotes the number of messages in _buffer` and moving the two together?
>> 
>> Could you elaborate this?  thanks?
>
>> When _sem.wait() returns, it just decreases one. however, _buffer.pop_all() pops all messages in queue at once. The two numbers are not consistent all the time.
> 
> Thank you for the explanation. I overlooked the fact that the "consumer" clears out the buffer in bulk.
> 
>> Could you elaborate this? thanks?
> 
> I mean that "_sem is a semaphore whose value denotes how many messages have been enqueued" is a bit inaccurate, because `write()` will decrement the semaphore value. For example, a producer has enqueued 2 msgs, but `_sem` could be `0`, as `flush` has been called.
> 
> However, I don't see a easy way to "fix" this; I am OK with the current comment.

Technically, we can make _sem denotes "the number of messages in buffer". 
Semaphore.signal() can pass in an integer argument. It should increase the semaphore value count instead of just 1. 
I don't think it would help for performance but can avoid wasteful spin.  Let's do that later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 27 07:05:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 07:05:41 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Correct typos and add a comment for a corner case.
  
  Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
  in async mode.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3135/files
  - new: https://git.openjdk.java.net/jdk/pull/3135/files/2ffc33fe..b3d36cf3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=20-21

  Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135

PR: https://git.openjdk.java.net/jdk/pull/3135

From xliu at openjdk.java.net  Thu May 27 07:15:07 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 07:15:07 GMT
Subject: RFR: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <BhGfEk4aTUQmqNF8G-UQtNKCDtfer7IMoKTzAmCHXX8=.21603425-aa8c-4eed-bea9-8d18c6c461b5@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

Thanks. I see.  That's fine.  I don't think it's a good idea to keep using SFINAE. 
Let me close it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From stefank at openjdk.java.net  Thu May 27 07:15:06 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 27 May 2021 07:15:06 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6]
In-Reply-To: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
Message-ID: <vppezzVF1Dqm4_tYrVa-8ssZ5RFULMteG0dQIRoRhJ8=.cd8da840-13a6-436e-b1c6-07ffbe9eaff7@github.com>

On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

@vnkozlov Can we considered the proposed changes to HotSpot Coding Style sufficiently reviewed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From xliu at openjdk.java.net  Thu May 27 07:15:08 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 07:15:08 GMT
Subject: Withdrawn: 8266789: devirtualize find_node and remove of LinkedList
In-Reply-To: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
References: <Sp4fALnlrMYbEuKUuhDUPxE7-NHgD-h9eMolfSAcqgU=.f7644027-4ea2-47cb-b2e8-6668222cd6b7@github.com>
Message-ID: <j2pkomOUASR90XVadCCNcnfFQyYW-2Lm1sDIG9MrRng=.a1ac81bc-3ad1-4754-80d1-6149227cd1e1@github.com>

On Mon, 10 May 2021 07:49:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Devirtualize find, find_node and remove. This patch make both LinkedListImpl
> and SortedLinkedList more generic. If the client doesn't use those member functions,
> it's not necessary to define equals() for the user-defined class E.
> 
> Remove those 3 member functions from the pure interface LinkedList. subclasses
> implement them using regular member functions.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3944

From dholmes at openjdk.java.net  Thu May 27 07:19:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 07:19:23 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
Message-ID: <CFNqdNDdbPbaQe37xKwZWTxo4vEWo0GplHGHp7X5HGo=.e304fac4-5f19-4968-8bcd-bea2fbadd1c1@github.com>

On Thu, 27 May 2021 07:05:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typos and add a comment for a corner case.
>   
>   Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
>   in async mode.

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/logging/logConfiguration.cpp line 267:

> 265:     // User may disable a logOuput like this:
> 266:     // LogConfiguration::parse_log_arguments(filename, "all=off", "", "", &stream);
> 267:     // Just be conservative. Flush them all before deleting idx.

Thanks for the comment. Note that this is still a best-effort attempt because immediately after the flush completes further logging could happen before the idx is deleted. So the async writer thread can still encounter  a fatal error. But as this can only happen with direct internal/gtest use of the LogConfiguration API I don't think this is a concern. Had I understood the issue sooner (my fault) I would have suggested just fixing the test to disallow async mode rather than making a change to the functional code. But this is something we can re-examine later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From ayang at openjdk.java.net  Thu May 27 07:48:19 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 27 May 2021 07:48:19 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
Message-ID: <b9Oeu9Rd5fRuR70V6gjwFposIQbakxfH0O7rPS_zxCM=.20733a28-010d-42c7-8719-f598689b4685@github.com>

On Thu, 27 May 2021 07:05:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typos and add a comment for a corner case.
>   
>   Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
>   in async mode.

Marked as reviewed by ayang (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From boris.ulasevich at bell-sw.com  Thu May 27 08:29:36 2021
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Thu, 27 May 2021 11:29:36 +0300
Subject: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to
 uninitialized BasicObjectLock::_displaced_header
In-Reply-To: <CABQ9BCXaTUjaqAghQ1Yag3BpcrL=MzmNQjjCEdKsY720ECz40A@mail.gmail.com>
References: <CABQ9BCUZhfdOGZ3zyoNiU1urfCDyyNLDQnr+ogvWMbufBemMNQ@mail.gmail.com>
 <9b64f7d9-0d55-3896-ed11-9e2468bf5f43@oracle.com>
 <CABQ9BCV=WtPD2_RiqXrBTpNnjksj_W4OriA-MG8MtqETf2OKrw@mail.gmail.com>
 <CABQ9BCW+YBJ0+hazRcX1-wwmO-bAs_6YKu3eTMj0q0nqCwRkkA@mail.gmail.com>
 <c3b9fb15-ea91-a4cc-91cb-0497c1910ef0@bell-sw.com>
 <CABQ9BCUFTeyv1vqFt2BkjSw3+g7eu9oekzmFV2xQQL0ezw9PYA@mail.gmail.com>
 <c5427513-d770-4cad-182e-0c29f66e62b7@bell-sw.com>
 <CABQ9BCV9WNpGQ2XG_bmi0iEU1YOhB71BHRkWbLv=4mDtgoLhwA@mail.gmail.com>
 <CABQ9BCXaTUjaqAghQ1Yag3BpcrL=MzmNQjjCEdKsY720ECz40A@mail.gmail.com>
Message-ID: <d5ca5e0b-18ca-5113-4475-ac7e64e39751@bell-sw.com>

Hi Chris,

Good. Thank you! Here is the link on pull request:
https://github.com/openjdk/jdk/pull/4218

regards,
Boris

On 27.05.2021 07:37, Chris Cole wrote:
> Hi Boris,
>
> Here is an updated test case at
> https://github.com/chrishcole/jdk/blob/arm32_c1_monitor_bug/test/hotspot/jtreg/compiler/c1/Test8267042.java.
>
> Thanks,
> Chris
>
> On Mon, May 24, 2021 at 11:56 AM Chris Cole <chris at sageembedded.com> wrote:
>> Hi Boris,
>>
>> On Sun, May 23, 2021 at 1:38 PM Boris Ulasevich
>> <boris.ulasevich at bell-sw.com> wrote:
>>> Hi Chris,
>>>
>>> I checked that the fix works fine and does not bring any regression.
>>> Let me create pull request and sponsor the change.
>>> Here is the fix and reproducer I prepared for review:
>>> https://github.com/openjdk/jdk/compare/master...bulasevich:jdk-8267042-arm32-c1-lock-01
>> Sounds great. Looks good to me.
>>
>>> (I think it is worth simplifying the MonitorBugTest)
>> Yes, I agree. If you want I could try and simplify this, but won't
>> have time to work on this until tomorrow.
>>
>> Thanks,
>> Chris


From simonis at openjdk.java.net  Thu May 27 09:21:19 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 09:21:19 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
Message-ID: <z7R2B9DVwPcf4qW6okNhOIrEAjvG-Sy7qaDmcXaqaOM=.4d32bed3-0ca1-4e1f-b966-e3a2a770e4a6@github.com>

On Thu, 27 May 2021 07:05:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typos and add a comment for a corner case.
>   
>   Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
>   in async mode.

Still fine :)

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From ysuenaga at openjdk.java.net  Thu May 27 09:45:27 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 27 May 2021 09:45:27 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
Message-ID: <q4HbM_hkXAM2gkUmNN4uvJfy8LhnPEmk3fTFWRInhhk=.51de9f28-0945-4075-8ddf-0eb39f2db46c@github.com>

On Thu, 27 May 2021 07:05:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typos and add a comment for a corner case.
>   
>   Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
>   in async mode.

Still good!

-------------

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From mcimadamore at openjdk.java.net  Thu May 27 10:11:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:11:43 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v25]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <erIj_DmFu4Orix2G5Io5J8FPkGMpVIZHO3jihEl_LX0=.245ad3d5-2e7c-49db-9677-62f59532ab23@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Add missing `final` in some static fields
  * Downgrade native methods in ProgrammableUpcallHandler to package-private

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/e927c235..e1fcd2d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23-24

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From tschatzl at openjdk.java.net  Thu May 27 10:21:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 May 2021 10:21:05 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v3]
In-Reply-To: <zJc-t62PpdVrwPE99ggQByiS16jkHQVNTleJED_hY_I=.eb7a63fa-35f4-46fd-a30d-ca9d0f8acf55@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
 <zJc-t62PpdVrwPE99ggQByiS16jkHQVNTleJED_hY_I=.eb7a63fa-35f4-46fd-a30d-ca9d0f8acf55@github.com>
Message-ID: <6KHJn9bmVf6BnB5ZtM656ffOPY8mqhxNA5s6R_NXhHU=.2fa916ca-ba36-4ac9-8730-0900875f1128@github.com>

On Wed, 26 May 2021 16:15:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
>> 
>>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
>> 
>> Over time many problems with performance and in particular memory usage have been observed:
>> 
>> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
>> 
>> * there is a substantial memory overhead for managing the data structures: examples are
>>     * using separate (hash) tables for the three different types of card containers
>>     * there is significant unnecessary preallocation of memory for some of the card set containers
>>     * Containers store redundant information
>> 
>> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
>> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
>> 
>> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
>> 
>> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
>> 
>> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
>> 
>> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
>> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
>> 
>> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
>> 
>> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
>> 
>> This initial fully working change can be roughly described with the following properties:
>> 
>> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
>> 
>> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
>> 
>> * there are now four different container types and one meta-container type. These four actual containers are:
>>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
>> 
>> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
>> 
>> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
>> 
>> Testing: tier1-8 many times, manual and automated perf testing
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename FOUND

Fyi on the "Remove prefetching of log buffers" commit: testing on one particular machine showed that for some reason performance decreased to baseline (jdk17 levels).
I.e. when I factored out the changes in [JDK-8266821](https://bugs.openjdk.java.net/browse/JDK-8266821) I extended the prefetching from the merge remset phase only to also include the log buffers. This showed (minimal absolute) improvements on pause time for that phase, but overall after merging back that change seems to slow down mixed gcs on that machine.
Removing the prefetching for the log buffers improves pause times again quite a bit below jdk17/mainline levels.

I can extract this particular change again if desired.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4116

From simonis at openjdk.java.net  Thu May 27 10:26:46 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 10:26:46 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  8267555: Fix class file version during redefinition after 8238048

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4149/files
  - new: https://git.openjdk.java.net/jdk/pull/4149/files/25f07246..45d6d006

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=00-01

  Stats: 262 lines in 7 files changed: 102 ins; 150 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4149/head:pull/4149

PR: https://git.openjdk.java.net/jdk/pull/4149

From simonis at openjdk.java.net  Thu May 27 10:26:48 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 10:26:48 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <xQrlnSWUpwVA6Hr0tIfyhCXWOC6LFVKb1AImBzPF9Qk=.94f5dd5c-2945-49ba-8c10-c1cf18de4bfb@github.com>

On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

Hi Coleen,

thanks for reviewing my change. I've updated the code as suggested and moved the test to the new location. Thanks for pointing me to `RedefineClassHelper`. That considerably simplifies the test. Please let me know what you think?

Best regards,
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From simonis at openjdk.java.net  Thu May 27 10:26:52 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 10:26:52 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <h_kb477-bO0tB2eftLaL63bzxFpsG2DmQ2e4t902qtY=.9be30237-e896-499d-84e9-1d10d8f3c488@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <h_kb477-bO0tB2eftLaL63bzxFpsG2DmQ2e4t902qtY=.9be30237-e896-499d-84e9-1d10d8f3c488@github.com>
Message-ID: <AIveVwiegIWGcw0OxQAxbk1-KGtlYLJiI5ttLo50Z9E=.2f973dea-cc27-4248-83cb-94ae9f781a3d@github.com>

On Wed, 26 May 2021 16:42:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267555: Fix class file version during redefinition after 8238048
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1861:
> 
>> 1859:   // Save fields from the old_cp.
>> 1860:   merge_cp->copy_fields(old_cp(), true /* skip_version */);
>> 1861:   scratch_cp->copy_fields(old_cp(), true /* skip_version */);
> 
> Rather than calling copy_fields, maybe this should revert this:
> -  if (old_cp->has_dynamic_constant()) {
> -    merge_cp->set_has_dynamic_constant();
> -    scratch_cp->set_has_dynamic_constant();
> -  }
> 
> And then the merge_cp->copy_fields(scratch_cp); ?
> 
> The merged_cp should look like the scratch_cp (with version number and generic signature, etc) until after verification and then I guess it should look like the old_cp at the end in redefine_single_class().

Yes, that works as well. Updated as suggested.

> test/hotspot/jtreg/runtime/ConstantPool/ClassVersion/ClassVersionAfterRedefine.java line 1:
> 
>> 1: /*
> 
> Can you put this test in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses directory?
> All the tests do redefinition differently.  There is a library RedefineClassHelper that you might be able to use and not have to deal with starting the agent.
> 
> @ compile TestClassXXX.jasm   // this is the old one
> then in the test read all of TestClassNew.jasm bytecodes, and s/New/XXX/ and use
> RedefineClassHelper.redefine(TestClassXXX.class, newBytes);
> 
> See RedefineRunningMethods.java in that directory for an example.

Moved the test to `test/hotspot/jtreg/serviceability/jvmti/RedefineClasses` and use `RedefineClassHelper` as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From github.com+4146708+a74nh at openjdk.java.net  Thu May 27 10:30:40 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 27 May 2021 10:30:40 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v4]
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <yfhN11zm2ebuSZDLX_JQI2Ji445HQsejMDEfiGtYbVM=.0601c4d8-86fa-4c18-8bb9-3f666284a4d2@github.com>

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:

  Move pauth_ptr_is_raw check to frame constructor
  
  Change-Id: I52022fa64bf837de5f8b0050ebad2ad75edc9f59
  CustomizedGitHooks: yes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4029/files
  - new: https://git.openjdk.java.net/jdk/pull/4029/files/e7b220cb..0ec89d85

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=02-03

  Stats: 12 lines in 2 files changed: 3 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4029.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4029/head:pull/4029

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Thu May 27 10:30:42 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 27 May 2021 10:30:42 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <_RF42fybublrrONFhG88jYkGxklihFJo4bJXnHkvKmE=.a7e74140-277e-48f7-b4b4-244ba29c2108@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <_RF42fybublrrONFhG88jYkGxklihFJo4bJXnHkvKmE=.a7e74140-277e-48f7-b4b4-244ba29c2108@github.com>
Message-ID: <NyiJu-1V-GrMDMyEHQKjhV-rBnPTq5pT8XIh63uGFBs=.250190ca-e879-4fc7-82b9-7300416dde75@github.com>

On Tue, 25 May 2021 19:28:53 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> I see this pattern repeating:
> 
> ```
>    address sender_pc = this->sender_pc();
>    // Interpreter should never sign the return address.
>    assert(pauth_ptr_is_raw(sender_pc), "cannot be signed");
> 
>    return frame(sender_sp, unextended_sp, link(), sender_pc);
> ```
> 
> Why can't we just add the **assert** to the **frame()** constructor instead?

I've made this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Thu May 27 10:30:44 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 27 May 2021 10:30:44 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <o4DpcvHhgqpH1Lq310kbD4NmafJchP9Y0fYcn19e3cI=.32073d50-0f24-4f2d-bf04-a1815bea6ce7@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <o4DpcvHhgqpH1Lq310kbD4NmafJchP9Y0fYcn19e3cI=.32073d50-0f24-4f2d-bf04-a1815bea6ce7@github.com>
Message-ID: <Vd9a0SH6FNEroJ2SSLwVlzdxTyWZ6HoA_BZOdhqjffo=.7ccdc70b-5af4-4f12-9452-f0443ffd8523@github.com>

On Wed, 26 May 2021 08:23:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?

The current code is being fairly cautious:

Native frames: saved PC might be signed. Therefore strip the pc.

Interpreter frames and compiled frames: the PC should never be signed. Assert this is the case.

For both Interpreter and Native frames we are getting the pc via sender_pc(), so can't push the strip inside sender_pc().

Alternatively, we could always strip instead of asserting. But that's not quite as nice.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From tschatzl at openjdk.java.net  Thu May 27 10:35:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 May 2021 10:35:08 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v3]
In-Reply-To: <zJc-t62PpdVrwPE99ggQByiS16jkHQVNTleJED_hY_I=.eb7a63fa-35f4-46fd-a30d-ca9d0f8acf55@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
 <zJc-t62PpdVrwPE99ggQByiS16jkHQVNTleJED_hY_I=.eb7a63fa-35f4-46fd-a30d-ca9d0f8acf55@github.com>
Message-ID: <G2hRQ4xEmhuop8zLREPGYc0tIpR3wMqRCxALWEHIA9Y=.c983202e-d3ed-440b-925b-5838002663f2@github.com>

On Wed, 26 May 2021 16:15:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
>> 
>>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
>> 
>> Over time many problems with performance and in particular memory usage have been observed:
>> 
>> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
>> 
>> * there is a substantial memory overhead for managing the data structures: examples are
>>     * using separate (hash) tables for the three different types of card containers
>>     * there is significant unnecessary preallocation of memory for some of the card set containers
>>     * Containers store redundant information
>> 
>> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
>> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
>> 
>> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
>> 
>> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
>> 
>> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
>> 
>> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
>> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
>> 
>> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
>> 
>> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
>> 
>> This initial fully working change can be roughly described with the following properties:
>> 
>> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
>> 
>> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
>> 
>> * there are now four different container types and one meta-container type. These four actual containers are:
>>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
>> 
>> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
>> 
>> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
>> 
>> Testing: tier1-8 many times, manual and automated perf testing
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename FOUND

Another note, during development of this feature there obviously were optimizations and improvements that did not make the cut. I labelled them with a [gc-g1-remset](https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20gc-g1-remset) label in the bug tracker. Feel free to add or suggest other things.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4116

From mcimadamore at openjdk.java.net  Thu May 27 10:37:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:37:38 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v26]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <9sO-moMQsSpzVGkmQ50SQAS1dcBNpC0EyO83lwDGFNI=.a4c737f0-7d4f-43a7-a5f8-2a504b20690f@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into JEP-412
 - * Add missing `final` in some static fields
   * Downgrade native methods in ProgrammableUpcallHandler to package-private
 - Add sealed modifiers in morally sealed API interfaces
 - Merge branch 'master' into JEP-412
 - Fix VaList test
   Remove unused code in Utils
 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/7278f56b...8bbddfc2

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3699/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=25
  Stats: 14501 lines in 219 files changed: 8847 ins; 3642 del; 2012 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From dholmes at openjdk.java.net  Thu May 27 11:15:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 11:15:19 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <CFNqdNDdbPbaQe37xKwZWTxo4vEWo0GplHGHp7X5HGo=.e304fac4-5f19-4968-8bcd-bea2fbadd1c1@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
 <CFNqdNDdbPbaQe37xKwZWTxo4vEWo0GplHGHp7X5HGo=.e304fac4-5f19-4968-8bcd-bea2fbadd1c1@github.com>
Message-ID: <-15GgLEZdzZ5myCZ7napQLIXvV9T1X7dqfZbUPtaDio=.d5ef6d52-a5a4-40ca-a3a0-f24ec2b89ac6@github.com>

On Thu, 27 May 2021 07:15: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:
>> 
>>   Correct typos and add a comment for a corner case.
>>   
>>   Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
>>   in async mode.
>
> src/hotspot/share/logging/logConfiguration.cpp line 267:
> 
>> 265:     // User may disable a logOuput like this:
>> 266:     // LogConfiguration::parse_log_arguments(filename, "all=off", "", "", &stream);
>> 267:     // Just be conservative. Flush them all before deleting idx.
> 
> Thanks for the comment. Note that this is still a best-effort attempt because immediately after the flush completes further logging could happen before the idx is deleted. So the async writer thread can still encounter  a fatal error. But as this can only happen with direct internal/gtest use of the LogConfiguration API I don't think this is a concern. Had I understood the issue sooner (my fault) I would have suggested just fixing the test to disallow async mode rather than making a change to the functional code. But this is something we can re-examine later.

Note: my comment about further logging being possible is because I can't obviously tell that something prior to this would have caused it to be disabled. But that may be the case, and then there is no issue with the flush at  all.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From aph at openjdk.java.net  Thu May 27 12:52:15 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 27 May 2021 12:52:15 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <Vd9a0SH6FNEroJ2SSLwVlzdxTyWZ6HoA_BZOdhqjffo=.7ccdc70b-5af4-4f12-9452-f0443ffd8523@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <o4DpcvHhgqpH1Lq310kbD4NmafJchP9Y0fYcn19e3cI=.32073d50-0f24-4f2d-bf04-a1815bea6ce7@github.com>
 <Vd9a0SH6FNEroJ2SSLwVlzdxTyWZ6HoA_BZOdhqjffo=.7ccdc70b-5af4-4f12-9452-f0443ffd8523@github.com>
Message-ID: <kPxY55Aw1q9tm7m1JK3Vh4iEVK0nwND39tJny4-eGMg=.0bc512cd-8e29-4d4e-86eb-0d913879efdb@github.com>

On Thu, 27 May 2021 10:26:27 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 516:
>> 
>>> 514:   // to the stack. In addition, we do not know which key was used to sign it.
>>> 515:   // Therefore, all we can do is strip it.
>>> 516:   address sender_pc = pauth_strip_pointer(this->sender_pc());
>> 
>> Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?
>
>> Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?
> 
> The current code is being fairly cautious:
> 
> Native frames: saved PC might be signed. Therefore strip the pc.
> 
> Interpreter frames and compiled frames: the PC should never be signed. Assert this is the case.
> 
> For both Interpreter and Native frames we are getting the pc via sender_pc(), so can't push the strip inside sender_pc().
> 
> Alternatively, we could always strip instead of asserting. But that's not quite as nice.

Mmm, but you very easily fix that by defining `raw_sender_pc()`. Most users don't want to be bothered by this stuff, and having `sender_pc()` return an encrypted PC is, frankly, maintainer abuse. Anyone who wants the `raw_sender_pc()` should ask for it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From phh at openjdk.java.net  Thu May 27 13:18:19 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 27 May 2021 13:18:19 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
Message-ID: <YyuooHGM9R3NhglfFDdfolnvCx4e9VAKF6zrTjLaDYI=.87f75aeb-f1cc-4ec7-a861-2cf42b66eb03@github.com>

On Thu, 27 May 2021 07:05:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch provides a buffer to store asynchrounous messages and flush them to
>> underlying files periodically.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typos and add a comment for a corner case.
>   
>   Without that flush(), TEST='gtest:gtest:LogFileOutput*' can't pass
>   in async mode.

Still good.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3135

From coleenp at openjdk.java.net  Thu May 27 13:21:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 27 May 2021 13:21:08 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
Message-ID: <aYkfujXbeY308xJ_b5u_Dj-sYsXOmjF666oWw1Z4Yj8=.f8aeb31c-a73a-4170-a451-797826b31c89@github.com>

On Thu, 27 May 2021 10:26:46 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
>> 
>> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
>> 
>> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
>> 
>> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
>> 
>> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
>> 
>>   // Copy the "source file name" attribute from new class version
>>   the_class->set_source_file_name_index(
>>     scratch_class->source_file_name_index());
>> 
>> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267555: Fix class file version during redefinition after 8238048

Yes, this looks good.  Isn't RedefineClassHelper great?  Thanks!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4149

From github.com+28651297+mkartashev at openjdk.java.net  Thu May 27 16:14:38 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 27 May 2021 16:14:38 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3]
In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
Message-ID: <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com>

> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
> 
> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
> 
> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
> 
> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
> 
> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
> 
> Results from Linux:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1
> 
> 
> Results from Windows 10:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
> ==============================
> TEST SUCCESS
> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> 
> 
> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1

Maxim Kartashev has updated the pull request incrementally with two additional commits since the last revision:

 - Coding style-related corrections.
 - Corrected the test to use Platform.sharedLibraryExt()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4169/files
  - new: https://git.openjdk.java.net/jdk/pull/4169/files/fe661dff..c8ef8b64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=01-02

  Stats: 43 lines in 2 files changed: 7 ins; 9 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169

PR: https://git.openjdk.java.net/jdk/pull/4169

From github.com+28651297+mkartashev at openjdk.java.net  Thu May 27 16:14:43 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 27 May 2021 16:14:43 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
 <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
Message-ID: <NHU7HHehQrAFZR0Yj4OkSoNN1S3DkqMiweADs5Wy9Zk=.96aba109-8e86-4b87-b437-674996f2dc46@github.com>

On Thu, 27 May 2021 04:23:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maxim Kartashev 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:
>> 
>>   8195129: System.load() fails to load from unicode paths
>
> src/hotspot/os/windows/os_windows.cpp line 1462:
> 
>> 1460:   const int flag_source_str_is_null_terminated = -1;
>> 1461:   const int flag_estimate_chars_count = 0;
>> 1462:   int utf16_chars_count_estimated = MultiByteToWideChar(source_encoding,
> 
> Your local naming style is somewhat excessive. You could just comment the values of the flags when you pass them eg:
> 
> MultiByteToWideChar(source_encoding,
>                                     MB_ERR_INVALID_CHARS,
>                                    source_str,
>                                    -1, //source is null-terminated
>                                   NULL, // no output buffer
>                                   0); // calculate required buffer size
> 
> Or you could just add a comment before the call:
> 
> // Perform a dummy conversion so that we can get the required size of the buffer to
> // allocate. The source is null-terminated.
> 
> Trying to document parameter semantics by variable naming doesn't work in my opinion - at some point if you want to know you have to RTFM for the API.
> 
> And utf16_len is perfectly adequate for the returned size.

Fair enough. Corrected.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From github.com+4146708+a74nh at openjdk.java.net  Thu May 27 16:19:57 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 27 May 2021 16:19:57 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v5]
In-Reply-To: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
Message-ID: <XlqK9psWemdtot0BvP_MMfqmhZQnxQ8SVXyyeFWZ5ws=.d0c40bab-e2a7-4301-83fd-310ccd41d9ae@github.com>

> On PAC systems, native code may sign return addresses before saving
> them to the stack. We must ensure we strip the any signed bits in
> order to walk the stack.
> Add extra asserts in places where we do not expect saved return
> addresses to be signed.
> 
> On non-PAC systems, all PAC instructions are treated as NOPs.
> 
> On Apple, use the provided ptrauth interface instead of asm
> as the compiler may optimise further.
> 
> Fedora 33 compiles all distro packages using PAC. Running the distro
> provided OpenJDK-latest in GDB on a PAC system:
> 
> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
> (gdb) call (int)pns($sp, $fp, $pc)
> 
> "Executing pns"
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
> C  0x006ffffff74750c4
> C  0x0042fffff6a7f84c
> C  0x0037fffff7fa0954
> C  0x0030fffff7fa4540
> C  0x0078fffff7d980c8
> 
> OpenJDK with this patch at the same breakpoint:
> 
> (gdb) call (int)pns($sp, $fp, $pc)
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
> 
> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
> 
> "Executing pns"
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
> j  java.lang.System.initPhase2(ZZ)I+0 java.base
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
> C  [libjli.so+0x3860]  JavaMain+0x7c
> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
> C  [libpthread.so.0+0x80c8]  start_thread+0xd8

Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:

  Add sender_pc_raw()
  
  Change-Id: I865170d4462c2ff3a67cbee992eadad4810efebf
  CustomizedGitHooks: yes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4029/files
  - new: https://git.openjdk.java.net/jdk/pull/4029/files/0ec89d85..70d13e7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4029&range=03-04

  Stats: 11 lines in 2 files changed: 3 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4029.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4029/head:pull/4029

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+4146708+a74nh at openjdk.java.net  Thu May 27 16:19:59 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 27 May 2021 16:19:59 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v3]
In-Reply-To: <kPxY55Aw1q9tm7m1JK3Vh4iEVK0nwND39tJny4-eGMg=.0bc512cd-8e29-4d4e-86eb-0d913879efdb@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <yR2udEfSx7d8rrt--Yh458PfCenrln3o_ItSGiXSrn4=.1188feb5-9bf2-4efb-b72b-2693ef446421@github.com>
 <o4DpcvHhgqpH1Lq310kbD4NmafJchP9Y0fYcn19e3cI=.32073d50-0f24-4f2d-bf04-a1815bea6ce7@github.com>
 <Vd9a0SH6FNEroJ2SSLwVlzdxTyWZ6HoA_BZOdhqjffo=.7ccdc70b-5af4-4f12-9452-f0443ffd8523@github.com>
 <kPxY55Aw1q9tm7m1JK3Vh4iEVK0nwND39tJny4-eGMg=.0bc512cd-8e29-4d4e-86eb-0d913879efdb@github.com>
Message-ID: <49fkpobeDFAvHD3MBJ7H2rK0-W8eTr-AXAIwOMu72XI=.a0a6b4f3-a039-44e7-a53e-c9594a5d3405@github.com>

On Thu, 27 May 2021 12:48:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> Would it not make more sense to strip the `sender_pc()` ? Don't all users expect it to be stripped?
>> 
>> The current code is being fairly cautious:
>> 
>> Native frames: saved PC might be signed. Therefore strip the pc.
>> 
>> Interpreter frames and compiled frames: the PC should never be signed. Assert this is the case.
>> 
>> For both Interpreter and Native frames we are getting the pc via sender_pc(), so can't push the strip inside sender_pc().
>> 
>> Alternatively, we could always strip instead of asserting. But that's not quite as nice.
>
> Mmm, but you very easily fix that by defining `raw_sender_pc()`. Most users don't want to be bothered by this stuff, and having `sender_pc()` return an encrypted PC is, frankly, maintainer abuse. Anyone who wants the `raw_sender_pc()` should ask for it.

Ok, that way makes sense. Updated as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From github.com+28651297+mkartashev at openjdk.java.net  Thu May 27 16:21:09 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 27 May 2021 16:21:09 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
 <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
Message-ID: <w0U-1bT6uMGk7gE0zebJAt10_G1IAMdncvdhxDMRe5w=.19e3da01-3dae-4143-a641-f85d52f9bc3f@github.com>

On Thu, 27 May 2021 05:18:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maxim Kartashev 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:
>> 
>>   8195129: System.load() fails to load from unicode paths
>
> test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java line 48:
> 
>> 46:         } else {
>> 47:             throw new Error("Unsupported OS");
>> 48:         }
> 
> Please use the test library function `Platform.sharedLibraryExt()` to get the library file extension.

Thanks for the suggestion. Rewrote this piece.
(Side note: since the libraries' prefix differs between platforms also, it'd be nice to have something like `Platform.sharedLibraryName(name)`; this is the way all the code that uses `Platform.sharedLibraryExt()` is structured anyway. But I guess it's best not to conflate things).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From github.com+28651297+mkartashev at openjdk.java.net  Thu May 27 16:31:05 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 27 May 2021 16:31:05 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
 <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
Message-ID: <XWO2SnvUXCp6g8Hl-ShPlZaYTtoeInlffE8sCFZb0d8=.c2314757-1c2c-4aaa-950c-e88490d9858e@github.com>

On Thu, 27 May 2021 05:13:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maxim Kartashev 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:
>> 
>>   8195129: System.load() fails to load from unicode paths
>
> src/hotspot/os/windows/os_windows.cpp line 1541:
> 
>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) {
>> 1540:   LPWSTR utf16_name = NULL;
>> 1541:   errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name);
> 
> Do you have any figures on the cost of this additional conversion in relation to startup time?
> 
> I'm already concerned to see that we have to perform each conversion twice via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to actually get the characters! This seems potentially very inefficient.

I measured time spend converting the library path name relative to the overall time of a (successful) `os::dll_load()` call. It varies between a fraction of a percent to ~3% (see below for the actual data from a `release` build). I'll defer to your expertise wrt to these numbers.

What can be done here (without changing os::dll_load() API) is to have a "fast path" for ascii-only path names, in which case no conversion is necessary, and a "slow path" for all the rest. This will complicate things a bit, but not by much, I believe. I am certainly willing to give that a try. Let me know what do you think.



./build/windows-x86_64-server-release/images/jdk/bin/java -jar ./build/windows-x86_64-server-fastdebug/images/jdk/demo/jfc/SwingSet2/SwingSet2.jar
0.050% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
2.273% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.dll
0.177% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\net.dll
0.541% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\nio.dll
0.359% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\zip.dll
3.186% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
0.075% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\awt.dll
0.232% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\freetype.dll
0.136% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\fontmanager.dll
0.170% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\javajpeg.dll

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From xliu at openjdk.java.net  Thu May 27 16:39:29 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 16:39:29 GMT
Subject: Integrated: 8229517: Support for optional asynchronous/buffered
 logging
In-Reply-To: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
Message-ID: <d4bZoGkaYDBe-njlIUIjuFluB0vV8Jei8XhrgeowOiM=.32a01cec-ae1a-41b8-806e-309c26eb77a9@github.com>

On Mon, 22 Mar 2021 22:12:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch provides a buffer to store asynchrounous messages and flush them to
> underlying files periodically.

This pull request has now been integrated.

Changeset: 41185d38
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170
Stats:     719 lines in 23 files changed: 707 ins; 6 del; 6 mod

8229517: Support for optional asynchronous/buffered logging

Reviewed-by: ysuenaga, simonis, stuefe, phh, dholmes, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
Message-ID: <PVcp8pf1_KCxa_lAv-EYuhfoJ2XJ98AJmKrXQ6a_KEw=.4ce5565b-665e-4b2a-a240-3cfc6ef9e28d@github.com>

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From github.com+58006833+xbzhang99 at openjdk.java.net  Thu May 27 17:36:24 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Thu, 27 May 2021 17:36:24 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v2]
In-Reply-To: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
Message-ID: <-uL2Xl3RD6-QYEUniGR5ur7YbGLVsjRZnqWdQhkUIQg=.26632121-76b8-41ea-afaa-626e9502af07@github.com>

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Xubo Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8264543: Using Intel serialize instruction to replace cpuid in Cross modify fence, on supported platforms
  rebase with master

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3334/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3334&range=01
  Stats: 23 lines in 4 files changed: 16 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3334/head:pull/3334

PR: https://git.openjdk.java.net/jdk/pull/3334

From github.com+58006833+xbzhang99 at openjdk.java.net  Thu May 27 17:36:24 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Thu, 27 May 2021 17:36:24 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86
In-Reply-To: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
Message-ID: <UtVA7cfTX2eF_2-vzop6V8dUBGmUegtNsZlt-UZzZzE=.5c25c717-a671-4a04-a152-ce4bcbf38bff@github.com>

On Fri, 2 Apr 2021 23:14:44 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Could I please get someone to review this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3334

From xliu at openjdk.java.net  Thu May 27 18:03:24 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 27 May 2021 18:03:24 GMT
Subject: RFR: 8229517: Support for optional asynchronous/buffered logging
 [v22]
In-Reply-To: <-15GgLEZdzZ5myCZ7napQLIXvV9T1X7dqfZbUPtaDio=.d5ef6d52-a5a4-40ca-a3a0-f24ec2b89ac6@github.com>
References: <swXsb_zpumbuut3R7jdcW3I60Ww2aMKYS0mp00WA8js=.1ab9b977-e30b-43b5-aaea-01e0f427471a@github.com>
 <NgmEUb0fgTl6IeblcXpvysSEvgrnlRBeAN3jdBn0Ok4=.99130e97-77f0-4ad5-8920-601d24da9974@github.com>
 <CFNqdNDdbPbaQe37xKwZWTxo4vEWo0GplHGHp7X5HGo=.e304fac4-5f19-4968-8bcd-bea2fbadd1c1@github.com>
 <-15GgLEZdzZ5myCZ7napQLIXvV9T1X7dqfZbUPtaDio=.d5ef6d52-a5a4-40ca-a3a0-f24ec2b89ac6@github.com>
Message-ID: <ysZbVJWtnBEIJS4aYruMAiz9m3n_8_LF6sfAOgJBMbo=.2ba865a2-6ed6-487d-b0f8-593a956b8b5a@github.com>

On Thu, 27 May 2021 11:11:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/logging/logConfiguration.cpp line 267:
>> 
>>> 265:     // User may disable a logOuput like this:
>>> 266:     // LogConfiguration::parse_log_arguments(filename, "all=off", "", "", &stream);
>>> 267:     // Just be conservative. Flush them all before deleting idx.
>> 
>> Thanks for the comment. Note that this is still a best-effort attempt because immediately after the flush completes further logging could happen before the idx is deleted. So the async writer thread can still encounter  a fatal error. But as this can only happen with direct internal/gtest use of the LogConfiguration API I don't think this is a concern. Had I understood the issue sooner (my fault) I would have suggested just fixing the test to disallow async mode rather than making a change to the functional code. But this is something we can re-examine later.
>
> Note: my comment about further logging being possible is because I can't obviously tell that something prior to this would have caused it to be disabled. But that may be the case, and then there is no issue with the flush at  all.

Thanks for the reviewing.  Theoretically, it's possible to enqueue a log message after flush(). 
That's a race condition and even original synchronous logging can't handle it well.  We don't find code to do that. 

This output deletion is a classic safe memory reclamation. There's still room to improve it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3135

From gziemski at openjdk.java.net  Thu May 27 18:08:10 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 27 May 2021 18:08:10 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v5]
In-Reply-To: <XlqK9psWemdtot0BvP_MMfqmhZQnxQ8SVXyyeFWZ5ws=.d0c40bab-e2a7-4301-83fd-310ccd41d9ae@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <XlqK9psWemdtot0BvP_MMfqmhZQnxQ8SVXyyeFWZ5ws=.d0c40bab-e2a7-4301-83fd-310ccd41d9ae@github.com>
Message-ID: <IvAB6qc3DOdSMNj8a5UIqo20KF4_AJk9LbWyBHyOHq0=.db2e934e-415f-44b7-b646-1a9fcde330cd@github.com>

On Thu, 27 May 2021 16:19:57 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add sender_pc_raw()
>   
>   Change-Id: I865170d4462c2ff3a67cbee992eadad4810efebf
>   CustomizedGitHooks: yes

Changes requested by gziemski (Committer).

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 176:

> 174:                          - NativeInstruction::instruction_size);
> 175:   // Compiled code should not have signed the return address.
> 176:   assert(pauth_ptr_is_raw(pc), "cannot be signed");

Do we need this, now that we have the assert in frame constructor ?

src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 145:

> 143:                          - NativeInstruction::instruction_size);
> 144:   // Compiled code should not have signed the return address.
> 145:   assert(pauth_ptr_is_raw(pc), "cannot be signed");

Do we need this, now that we have the assert in frame constructor ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4029

From gziemski at openjdk.java.net  Thu May 27 18:17:06 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 27 May 2021 18:17:06 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86
In-Reply-To: <GLq7FGX_iiix9eq0cuAcOTdIC2auEyjcj4ihLAULKI8=.70989a95-1b9c-4ce5-adce-e89825eaa81e@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
 <GLq7FGX_iiix9eq0cuAcOTdIC2auEyjcj4ihLAULKI8=.70989a95-1b9c-4ce5-adce-e89825eaa81e@github.com>
Message-ID: <i3_Y3_u5xMITEgtlThaI38h6Y1iHj015F-GVIx8CpRo=.f15a7ae1-8339-498c-b078-25edd8dc7df8@github.com>

On Thu, 8 Apr 2021 15:29:56 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> If this is an optimization, do you have any numbers that show an improvement with this change?

> @gerard-ziemski Hi, could you review the patch? thanks.

Sorry xbzhang99, I do not know enough x86 assembly to actually review it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3334

From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From lmesnik at openjdk.java.net  Thu May 27 20:20:22 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 27 May 2021 20:20:22 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace
Message-ID: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>

8265148: StackWatermarkSet being updated during AsyncGetCallTrace

-------------

Commit messages:
 - space removed.
 - 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Changes: https://git.openjdk.java.net/jdk/pull/4217/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4217&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265148
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4217.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4217/head:pull/4217

PR: https://git.openjdk.java.net/jdk/pull/4217

From lmesnik at openjdk.java.net  Thu May 27 20:20:22 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 27 May 2021 20:20:22 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <Fbhme2KVcKdDfmGd8tFycrlsq6HApTtEpLpcjV1evnE=.055ab6ed-735f-49b7-a4b0-bad0777d6c0d@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

I verified that running sunflow with async-profiler crashed VM before the fix and finished successfully after the fix. I compared data for G1GC for older JDK before https://bugs.openjdk.java.net/browse/JDK-8253180 is implemented. The results look pretty similar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4217

From kbarrett at openjdk.java.net  Thu May 27 20:21:23 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 27 May 2021 20:21:23 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v2]
In-Reply-To: <-uL2Xl3RD6-QYEUniGR5ur7YbGLVsjRZnqWdQhkUIQg=.26632121-76b8-41ea-afaa-626e9502af07@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
 <-uL2Xl3RD6-QYEUniGR5ur7YbGLVsjRZnqWdQhkUIQg=.26632121-76b8-41ea-afaa-626e9502af07@github.com>
Message-ID: <-kwQNgPYhE7PXGlZBVYX507-ROD8DmYSMO6jxfjoxEA=.e99aaba5-fa08-4c10-ac99-8df7822e6de6@github.com>

On Thu, 27 May 2021 17:36:24 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8264543: Using Intel serialize instruction to replace cpuid in Cross modify fence, on supported platforms
>   rebase with master

Just a drive-by comment, not a review.

This change is (necessarily) kind of messy because of the needed low-level
conditionalization.  So it really ought to be supported by benchmark data to
argue that it's worth the effort, both now and in future maintenance.

If the performance impact of this change makes it worth doing, then it
probably ought not be limited to Linux, but should be done for all OS's that
run on x86.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3334

From sspitsyn at openjdk.java.net  Thu May 27 21:31:05 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 27 May 2021 21:31:05 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
Message-ID: <uQPa1I7oV3HTmMKrp7cLtnBoP0KAKShXTVtcwKTuy8U=.badb9edc-26f9-4794-94e3-a8ade4d4f170@github.com>

On Thu, 27 May 2021 10:26:46 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
>> 
>> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
>> 
>> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
>> 
>> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
>> 
>> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
>> 
>>   // Copy the "source file name" attribute from new class version
>>   the_class->set_source_file_name_index(
>>     scratch_class->source_file_name_index());
>> 
>> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267555: Fix class file version during redefinition after 8238048

Hi Volker,
The fix looks okay to me.
Thank you for fixing it!
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4149

From lmesnik at openjdk.java.net  Thu May 27 22:18:26 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 27 May 2021 22:18:26 GMT
Subject: RFR: 8267893: Improve EFH do get native/mixed stack traces for cores
 and live processes
Message-ID: <Lrg22L3euNbjatt3J_KXH9T5tULsoDzsR9MlGrLrQlk=.94fee158-b9b3-4cf5-a2ee-a71232386d2d@github.com>

EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated.

-------------

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into efh
 - EFH improvements

Changes: https://git.openjdk.java.net/jdk/pull/4234/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267893
  Stats: 188 lines in 13 files changed: 158 ins; 6 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

From dholmes at openjdk.java.net  Thu May 27 23:02:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 23:02:05 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86
In-Reply-To: <V3E1cfSu5f2K4X8u9wz3TgqvXshgTHO7FEsx1RNxJAs=.912838e0-8f48-4f96-9862-c9af48a0aab2@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
 <V3E1cfSu5f2K4X8u9wz3TgqvXshgTHO7FEsx1RNxJAs=.912838e0-8f48-4f96-9862-c9af48a0aab2@github.com>
Message-ID: <svS4xUQSXEB9zv6qvSAqiJpSq9q-1TebgeQ0G_KIWuA=.e97385f8-4e05-463e-ad4b-6e77a03cd7c3@github.com>

On Tue, 4 May 2021 01:01:25 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

> Although we don't have benchmark data yet, serialize is the recommended alternative vs. using CPUID. 

I don't see any rush to make this change so there is time to gather the missing benchmark data. If Intel recommend making this change then we should definitely consider it, but we need to know that it won't adversely affect anyone first. And as Kim said this should be done for all x86 in that case.

> Also, in the virtual machine environment, serialize provides full/fast serialization without causing VMEXIT

Sorry what do you mean by this?

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/3334

From dholmes at openjdk.java.net  Thu May 27 23:11:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 23:11:06 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Hi Leonid,

Someone familiar with Stackwatermarks will need to comment about the validity of doing this, my only comment is to document why it is being turned off.

Thanks,
David

src/hotspot/share/prims/forte.cpp line 326:

> 324:     int loop_count;
> 325:     int loop_max = MaxJavaStackTraceDepth * 2;
> 326:     RegisterMap map(thread, false, false);

Can we add some comments as to what the false parameters mean please.

RegisterMap map(thread, false /* no update */, false /*no stackwatermark frame processing */);

Though it may be that a more elaborate block comment is needed to explain why we don't want stackwatermark frame processing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4217

From dholmes at openjdk.java.net  Thu May 27 23:42:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 23:42:08 GMT
Subject: RFR: 8267893: Improve EFH do get native/mixed stack traces for
 cores and live processes
In-Reply-To: <Lrg22L3euNbjatt3J_KXH9T5tULsoDzsR9MlGrLrQlk=.94fee158-b9b3-4cf5-a2ee-a71232386d2d@github.com>
References: <Lrg22L3euNbjatt3J_KXH9T5tULsoDzsR9MlGrLrQlk=.94fee158-b9b3-4cf5-a2ee-a71232386d2d@github.com>
Message-ID: <cbIPDbvuOraMGDOE35Hrh36xx12r8caMJMxjDdBSJc8=.39038cab-539e-4189-aaab-09d2b0bd4b1f@github.com>

On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated.

Hi Leonid,

What is EFH? Please update the bug and PR to explain.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4234

From lmesnik at openjdk.java.net  Fri May 28 00:57:09 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 28 May 2021 00:57:09 GMT
Subject: RFR: 8267893: Improve jtreg test failure handler do get
 native/mixed stack traces for cores and live processes
In-Reply-To: <cbIPDbvuOraMGDOE35Hrh36xx12r8caMJMxjDdBSJc8=.39038cab-539e-4189-aaab-09d2b0bd4b1f@github.com>
References: <Lrg22L3euNbjatt3J_KXH9T5tULsoDzsR9MlGrLrQlk=.94fee158-b9b3-4cf5-a2ee-a71232386d2d@github.com>
 <cbIPDbvuOraMGDOE35Hrh36xx12r8caMJMxjDdBSJc8=.39038cab-539e-4189-aaab-09d2b0bd4b1f@github.com>
Message-ID: <dMtFeLCsr_pLviS3zkgxgQAwi2-99zf9R8wx5iE37Ac=.09238ee3-f2f8-4230-8246-5850a1fc111e@github.com>

On Thu, 27 May 2021 23:38:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Leonid,
> 
> What is EFH? Please update the bug and PR to explain.
> 
> Thanks,
> David

Updated summary to "Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4234

From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
Message-ID: <hhtFKkkecHjmFc0a4jIaZsr7J9jfbBBCIl2z45lU8Rk=.f90b843b-b655-4106-83ee-dcfd9edfdee2@github.com>

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From iignatyev at openjdk.java.net  Fri May 28 02:29:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 28 May 2021 02:29:06 GMT
Subject: RFR: 8267893: Improve jtreg test failure handler do get
 native/mixed stack traces for cores and live processes
In-Reply-To: <Lrg22L3euNbjatt3J_KXH9T5tULsoDzsR9MlGrLrQlk=.94fee158-b9b3-4cf5-a2ee-a71232386d2d@github.com>
References: <Lrg22L3euNbjatt3J_KXH9T5tULsoDzsR9MlGrLrQlk=.94fee158-b9b3-4cf5-a2ee-a71232386d2d@github.com>
Message-ID: <M2mHc_6yJdUR8MBGCViaM--XpPjmagWAjy2V8jgqMww=.8c05e813-ac9e-4d0b-b55f-35e4459d3144@github.com>

On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated.

@lmesnik , how has this been tested?

test/failure_handler/Makefile line 41:

> 39: CONF_DIR = src/share/conf
> 40: 
> 41: JAVA_RELEASE = 7

could you please update `DEPENDENCES` section in `test/failure_handler/README`?

test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java line 69:

> 67:                 }
> 68:             } catch (IOException ioe) {
> 69:                 // just silently skip gzipped core processing

we don't silently ignore exceptions in `failure_handler`, we tend to print them so we at least have some echoes of what happened.

test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java line 71:

> 69:                 // just silently skip gzipped core processing
> 70:             }
> 71:             unpackedCore.toFile().delete();

Suggestion:

            Paths.delete(unpackedCore);
``` ?

test/failure_handler/src/share/classes/jdk/test/failurehandler/Utils.java line 73:

> 71:         InputStream stream = Utils.class.getResourceAsStream(resourceName);
> 72: 
> 73:         // EFH_CONF_DIR might re-defined to load custom configs for development purposes

this also seems to be unrelated to the subject and does require documentation in `test/failure_handler/README`.

test/failure_handler/src/share/classes/jdk/test/failurehandler/action/PatternAction.java line 63:

> 61:         }
> 62:         for (int i = 0, n = args.length; i < n; ++i) {
> 63:             args[i] = args[i].replace("%java", helper.findApp("java").getAbsolutePath());

are we sure that `java` from `PATH` (which is what `findApp` returns) is the right `java`?

test/failure_handler/src/share/conf/common.properties line 38:

> 36:         jcmd.vm.system_properties \
> 37:   jcmd.gc.heap_info jcmd.gc.class_histogram jcmd.gc.finalizer_info \
> 38:   jcmd.vm.info \

this seems to be unrelated to the RFE you are working on.

test/failure_handler/src/share/conf/common.properties line 67:

> 65: cores=jhsdb.jstack
> 66: jhsdb.jstack.app=jhsdb
> 67: jhsdb.jstack.args=jstack --mixed --core %p --exe %java

strictly speaking, we can't guarantee that the executable is always `bin/java`, but it's the most common and the most interesting case, so this assumption is good enough for our pourposes.

could you please add a comment explaining this so the further reading won't be puzzled?

test/failure_handler/src/share/conf/mac.properties line 68:

> 66: native.jhsdb.app=bash
> 67: native.jhsdb.jstack.delimiter=\0
> 68: native.jhsdb.jstack.args=-c\0DevToolsSecurity --status | grep -q enabled && jhsdb jstack --mixed --pid %p

AFAICS `jhsdb` does check "Developer mode" on macos before trying to attach and will just report 'lack of privileges' (as opposed to hanging with a modal window asking for permission), so you can move `jshdb.jstack` to `common.properties`.

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4234

From github.com+58006833+xbzhang99 at openjdk.java.net  Fri May 28 04:37:07 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Fri, 28 May 2021 04:37:07 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86
In-Reply-To: <svS4xUQSXEB9zv6qvSAqiJpSq9q-1TebgeQ0G_KIWuA=.e97385f8-4e05-463e-ad4b-6e77a03cd7c3@github.com>
References: <EIDTq0P5BsnKa_rMbc6jAQ9nLgZrVmfalm2YtqXI4PQ=.1249f583-8b81-4a5f-beb1-83ebed305453@github.com>
 <V3E1cfSu5f2K4X8u9wz3TgqvXshgTHO7FEsx1RNxJAs=.912838e0-8f48-4f96-9862-c9af48a0aab2@github.com>
 <svS4xUQSXEB9zv6qvSAqiJpSq9q-1TebgeQ0G_KIWuA=.e97385f8-4e05-463e-ad4b-6e77a03cd7c3@github.com>
Message-ID: <6gJZMf05x2OVpIJyQVglz6W0VLWOQzcvGBOxPKK0rco=.9e3fda3c-ae56-47e1-bbcb-f8a825254cd4@github.com>

On Thu, 27 May 2021 22:59:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi Gerard,
>> Although we don't have benchmark data yet, serialize is the recommended alternative vs. using CPUID. Also, in the virtual machine environment, serialize provides full/fast serialization without causing VMEXIT
>
>> Although we don't have benchmark data yet, serialize is the recommended alternative vs. using CPUID. 
> 
> I don't see any rush to make this change so there is time to gather the missing benchmark data. If Intel recommend making this change then we should definitely consider it, but we need to know that it won't adversely affect anyone first. And as Kim said this should be done for all x86 in that case.
> 
>> Also, in the virtual machine environment, serialize provides full/fast serialization without causing VMEXIT
> 
> Sorry what do you mean by this?
> 
> Thanks,
> David

@dholmes-ora VM exit is transitioning from a running VM to the hypervisor. The processor has to save the state of the VM. It is a costly operation. The cpuid instruction requires VM exit (https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf  25.1.2)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3334

From dholmes at openjdk.java.net  Fri May 28 05:50:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 28 May 2021 05:50:06 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <XWO2SnvUXCp6g8Hl-ShPlZaYTtoeInlffE8sCFZb0d8=.c2314757-1c2c-4aaa-950c-e88490d9858e@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
 <CGWudgWLXzbva7SE18Vg5apFCDlp4_BJc16raTUvAbE=.1c08d314-266c-463c-a4c2-0ffdbdd4d461@github.com>
 <z_uIziE-ZpxzJ1RWgKfWIAuye3CLeHg2M_5ajt4fZCE=.09176f83-371a-4d0a-bc6d-ebcaccca17fe@github.com>
 <XWO2SnvUXCp6g8Hl-ShPlZaYTtoeInlffE8sCFZb0d8=.c2314757-1c2c-4aaa-950c-e88490d9858e@github.com>
Message-ID: <ErTAxJ7jW-MIzZoQoUr10DB265VTj3-dbfbR3antWhE=.7fdebfb6-acea-43ed-affe-2ce578440013@github.com>

On Thu, 27 May 2021 16:28:14 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 1541:
>> 
>>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) {
>>> 1540:   LPWSTR utf16_name = NULL;
>>> 1541:   errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name);
>> 
>> Do you have any figures on the cost of this additional conversion in relation to startup time?
>> 
>> I'm already concerned to see that we have to perform each conversion twice via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to actually get the characters! This seems potentially very inefficient.
>
> I measured time spend converting the library path name relative to the overall time of a (successful) `os::dll_load()` call. It varies between a fraction of a percent to ~3% (see below for the actual data from a `release` build). I'll defer to your expertise wrt to these numbers.
> 
> What can be done here (without changing os::dll_load() API) is to have a "fast path" for ascii-only path names, in which case no conversion is necessary, and a "slow path" for all the rest. This will complicate things a bit, but not by much, I believe. I am certainly willing to give that a try. Let me know what do you think.
> 
> 
> 
> ./build/windows-x86_64-server-release/images/jdk/bin/java -jar ./build/windows-x86_64-server-fastdebug/images/jdk/demo/jfc/SwingSet2/SwingSet2.jar
> 0.050% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
> 2.273% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.dll
> 0.177% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\net.dll
> 0.541% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\nio.dll
> 0.359% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\zip.dll
> 3.186% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
> 0.075% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\awt.dll
> 0.232% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\freetype.dll
> 0.136% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\fontmanager.dll
> 0.170% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\javajpeg.dll

The core-libs folks have the experience/expertise with these character encoding issues so I will defer to them. But someone should run this through our startup benchmarks to see if it makes a difference.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From stefank at openjdk.java.net  Fri May 28 07:15:01 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 07:15:01 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <MfPw3vK_xlSoeP9gu_V7e0BgGhpFuEQCr67GgXjtH-E=.388104e8-d7d0-475c-a6c4-8f884fb70e3b@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Looks good. Could you verify the fix with ZGC? G1 doesn't use it, so testing with G1 will only show that we don't hit the failing assert anymore.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4217

From stefank at openjdk.java.net  Fri May 28 07:24:37 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 07:24:37 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v7]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <TWlRdyfYQGw3V7VvZj79_r7HZBH_xpdIas1WlgIR2Gw=.52b9787a-4d85-4109-96ab-b18ab9c61146@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Review kbarrett
 - Review dholmes
 - Update HotSpot style guide documents
 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Clean up assembler_<cpu>.inline.hpp
 - 8267464: Circular-dependency resiliant inline headers

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=06
  Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From ayang at openjdk.java.net  Fri May 28 08:18:25 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 May 2021 08:18:25 GMT
Subject: RFR: JDK-8267916: Make as_CompilerThread consistent with other
 as_*_thread methods
Message-ID: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>

Simple refactoring around `as_CompilerThread`. A new file, `compilerThread.inline.hpp`, is created to get around the circular dependency.

-------------

Commit messages:
 - compiler_thread

Changes: https://git.openjdk.java.net/jdk/pull/4240/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4240&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267916
  Stats: 64 lines in 13 files changed: 50 ins; 9 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4240/head:pull/4240

PR: https://git.openjdk.java.net/jdk/pull/4240

From aph at openjdk.java.net  Fri May 28 08:20:13 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 28 May 2021 08:20:13 GMT
Subject: RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems
 [v5]
In-Reply-To: <XlqK9psWemdtot0BvP_MMfqmhZQnxQ8SVXyyeFWZ5ws=.d0c40bab-e2a7-4301-83fd-310ccd41d9ae@github.com>
References: <3Ak1iZsEfTEKadfUcF6zGVuzsDoiQbaupm66NvSwlaY=.8323de39-d7e6-4049-9243-7c31a75bbc9f@github.com>
 <XlqK9psWemdtot0BvP_MMfqmhZQnxQ8SVXyyeFWZ5ws=.d0c40bab-e2a7-4301-83fd-310ccd41d9ae@github.com>
Message-ID: <tnrT55fOgmIQR5Mu4jWYb9nQ0zL2xpovebpfl0pcqfQ=.72082f49-bb39-4ae0-a284-ba0628aceb41@github.com>

On Thu, 27 May 2021 16:19:57 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> On PAC systems, native code may sign return addresses before saving
>> them to the stack. We must ensure we strip the any signed bits in
>> order to walk the stack.
>> Add extra asserts in places where we do not expect saved return
>> addresses to be signed.
>> 
>> On non-PAC systems, all PAC instructions are treated as NOPs.
>> 
>> On Apple, use the provided ptrauth interface instead of asm
>> as the compiler may optimise further.
>> 
>> Fedora 33 compiles all distro packages using PAC. Running the distro
>> provided OpenJDK-latest in GDB on a PAC system:
>> 
>> Thread 2 "java" hit Breakpoint 1, 0x0000fffff68d7fe4 in init_globals() ()
>>    from /usr/lib/jvm/java-16-openjdk-16.0.1.0.9-1.rolling.fc33.aarch64-fastdebug/lib/server/libjvm.so
>> (gdb) call (int)pns($sp, $fp, $pc)
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xe26fe4]  init_globals()+0x10
>> C  0x006ffffff74750c4
>> C  0x0042fffff6a7f84c
>> C  0x0037fffff7fa0954
>> C  0x0030fffff7fa4540
>> C  0x0078fffff7d980c8
>> 
>> OpenJDK with this patch at the same breakpoint:
>> 
>> (gdb) call (int)pns($sp, $fp, $pc)
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x189c47c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x27c
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>> 
>> OpenJDK with this patch breakpointed at pd_hotspot_signal_handler:
>> 
>> "Executing pns"
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x148a730]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x0
>> C  [linux-vdso.so.1+0x80c]  __kernel_rt_sigreturn+0x0
>> J 53 c1 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base (98 bytes) @ 0x0000ffffe159cc3c [0x0000ffffe159cb40+0x00000000000000fc]
>> j  jdk.internal.org.objectweb.asm.SymbolTable.setMajorVersionAndClassName(ILjava/lang/String;)I+12 java.base
>> j  jdk.internal.org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V+20 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.classFilePrologue()Ljdk/internal/org/objectweb/asm/ClassWriter;+30 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+1 java.base
>> j  java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+27 java.base
>> j  java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base
>> j  java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+792 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/LambdaForm;+17 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/LambdaForm;+163 java.base
>> j  java.lang.invoke.DirectMethodHandle.preparedLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm;+2 java.base
>> j  java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle;+159 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;ZZLjava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+210 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/invoke/MethodHandles$Lookup;)Ljava/lang/invoke/MethodHandle;+14 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(BLjava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/MethodHandle;+31 java.base
>> j  java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+153 java.base
>> j  java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(Ljava/lang/Class;ILjava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+38 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x184b778]  SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, Symbol*, Symbol*, Thread*)+0x398
>> V  [libjvm.so+0xa1f104]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, Thread*)+0xca0
>> V  [libjvm.so+0xa1fb6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, Thread*)+0x3fc
>> V  [libjvm.so+0x6bef6c]  BootstrapInfo::resolve_args(Thread*)+0xcbc
>> V  [libjvm.so+0x6c1538]  BootstrapInfo::resolve_bsm(Thread*)+0x1194
>> V  [libjvm.so+0x184d300]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, Thread*)+0x30
>> V  [libjvm.so+0x120450c]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, Thread*)+0x2c
>> V  [libjvm.so+0x1204b1c]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, Thread*)+0x1bc
>> V  [libjvm.so+0xe0ecc4]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x190
>> V  [libjvm.so+0xe123a0]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x160
>> j  jdk.internal.module.ModulePath.explodedPackages(Ljava/nio/file/Path;)Ljava/util/Set;+5 java.base
>> j  jdk.internal.module.ModulePath.lambda$readExplodedModule$9(Ljava/nio/file/Path;)Ljava/util/Set;+2 java.base
>> j  jdk.internal.module.ModulePath$$Lambda$2+0x000000010003bbe0.get()Ljava/lang/Object;+8 java.base
>> j  jdk.internal.module.ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;+762 java.base
>> j  jdk.internal.module.ModuleInfo.read(Ljava/io/InputStream;Ljava/util/function/Supplier;)Ljdk/internal/module/ModuleInfo$Attributes;+16 java.base
>> j  jdk.internal.module.ModulePath.readExplodedModule(Ljava/nio/file/Path;)Ljava/lang/module/ModuleReference;+35 java.base
>> j  jdk.internal.module.ModulePath.readModule(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Ljava/lang/module/ModuleReference;+11 java.base
>> j  jdk.internal.module.ModulePath.scanDirectory(Ljava/nio/file/Path;)Ljava/util/Map;+69 java.base
>> j  jdk.internal.module.ModulePath.scan(Ljava/nio/file/Path;)Ljava/util/Map;+60 java.base
>> j  jdk.internal.module.ModulePath.scanNextEntry()V+23 java.base
>> j  jdk.internal.module.ModulePath.find(Ljava/lang/String;)Ljava/util/Optional;+36 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.lambda$find$0(Ljava/lang/module/ModuleFinder;Ljava/lang/String;)Ljava/util/Optional;+2 java.base
>> j  jdk.internal.module.SystemModuleFinders$1$$Lambda$1+0x0000000100033b00.run()Ljava/lang/Object;+8 java.base
>> j  java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base
>> j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+5 java.base
>> j  jdk.internal.module.SystemModuleFinders$1.find(Ljava/lang/String;)Ljava/util/Optional;+12 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+304 java.base
>> j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base
>> j  java.lang.System.initPhase2(ZZ)I+0 java.base
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xe20118]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x5c8
>> V  [libjvm.so+0xe20f64]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x284
>> V  [libjvm.so+0x189c7bc]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x5bc
>> V  [libjvm.so+0xf527a0]  JNI_CreateJavaVM+0xc0
>> C  [libjli.so+0x3860]  JavaMain+0x7c
>> C  [libjli.so+0x732c]  ThreadJavaMain+0xc
>> C  [libpthread.so.0+0x80c8]  start_thread+0xd8
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add sender_pc_raw()
>   
>   Change-Id: I865170d4462c2ff3a67cbee992eadad4810efebf
>   CustomizedGitHooks: yes

OK, that's much better.

-------------

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4029

From simonis at openjdk.java.net  Fri May 28 08:36:09 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 28 May 2021 08:36:09 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <uQPa1I7oV3HTmMKrp7cLtnBoP0KAKShXTVtcwKTuy8U=.badb9edc-26f9-4794-94e3-a8ade4d4f170@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
 <uQPa1I7oV3HTmMKrp7cLtnBoP0KAKShXTVtcwKTuy8U=.badb9edc-26f9-4794-94e3-a8ade4d4f170@github.com>
Message-ID: <8II7jI95WRg4a_7C-LgrZdQro-CTGErSHJlzvq-LQgc=.031c253b-f484-488e-8784-6d0240987b90@github.com>

On Thu, 27 May 2021 21:28:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267555: Fix class file version during redefinition after 8238048
>
> Hi Volker,
> The fix looks okay to me.
> Thank you for fixing it!
> Serguei

Thanks for the reviews @sspitsyn and @coleenp.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From simonis at openjdk.java.net  Fri May 28 08:36:10 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 28 May 2021 08:36:10 GMT
Subject: Integrated: 8267555: Fix class file version during redefinition after
 8238048
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <EdqsL71aym5FO6eB5lO9UOIBRNg5MPM6QcUdd8yWASE=.8c24c252-8e22-47eb-bdc3-872cab2cba3f@github.com>

On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

This pull request has now been integrated.

Changeset: 1d2c7ac3
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1d2c7ac3f7492b335757bf0fd3f6ca3941c5fc72
Stats:     208 lines in 5 files changed: 204 ins; 1 del; 3 mod

8267555: Fix class file version during redefinition after 8238048

Reviewed-by: coleenp, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From iignatyev at openjdk.java.net  Fri May 28 08:37:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 28 May 2021 08:37:19 GMT
Subject: RFR: 8267917: mark hotspot containers tests which ignore external VM
 flags
Message-ID: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com>

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

-------------

Commit messages:
 - 8267917

Changes: https://git.openjdk.java.net/jdk/pull/4241/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4241&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267917
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4241.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4241/head:pull/4241

PR: https://git.openjdk.java.net/jdk/pull/4241

From neliasso at openjdk.java.net  Fri May 28 09:16:25 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 28 May 2021 09:16:25 GMT
Subject: RFR: 8267726: ZGC: array_copy_requires_gc_barriers too strict
Message-ID: <t-qEjX3CnUyo5ZNfHNJ41SQA46qlOmaZ5Y9YGMC0baA=.8335064b-1e9e-4cd1-962d-04b815ba330a@github.com>

I found some cases where an arraycopy clone is eliminated with G1 but not with ZGC. This is probably something that wasn't updated fully after the transition to late gc barrier insertion.

During parse and optimizaton phases array_copy_requires_gc_barriers should return false for clones of oop-arrays. Clone of oop-arrays should be treated the same way as clones of primitive-arrays. During optimization phase - only clones of instances should return true - and that's because they can't be reduced to a raw bulk copy, Clones of instances must either become deconstructed into field copies, or be handled in a special call.

During expansion array_copy_requires_gc_barriers must return true - because we must use a copy with barriers.

To fix this I had to add an extra field to array_copy_requires_gc_barriers to be able to handle instance clones separately. I will follow up with a cleanup. The intersection of arraycopy-kinds and array_copy_requires_gc_barriers-method is the source of much unnecessary complexity. 

Please review,
Best regards,
Nils Eliasson

-------------

Commit messages:
 - Fix array_copy_requires_gc_barriers
 - adapt opt
 - Fix barrier requirement

Changes: https://git.openjdk.java.net/jdk/pull/4230/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4230&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267726
  Stats: 21 lines in 10 files changed: 9 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4230.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4230/head:pull/4230

PR: https://git.openjdk.java.net/jdk/pull/4230

From neliasso at openjdk.java.net  Fri May 28 09:52:06 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 28 May 2021 09:52:06 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <FGcLlLw6dp7DN8CoQgrjUwHmZnzDrSZ_eZPjapfyCMA=.1c813845-814d-482c-9cdf-f40b1b82d38a@github.com>

On Fri, 14 May 2021 00:42:35 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

Added hotspot-compiler label

-------------

PR: https://git.openjdk.java.net/jdk/pull/4019

From stefank at openjdk.java.net  Fri May 28 11:19:25 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 11:19:25 GMT
Subject: RFR: 8267914: Remove DeferredObjectToKlass workaround
Message-ID: <KB3Y4los1LsDtwH_erMi-GQvw8ARkMiShGIWzaZ9yf0=.7cc27017-c52a-496e-a72b-c6adf949adcd@github.com>

In JKD-8229839 we fixed a circular dependency problem between oop.inline.hpp and markWord.inline.hpp.  When JDK-8267464: 
'Circular-dependency resilient inline headers' gets integrated, this workaround isn't needed anymore.

-------------

Commit messages:
 - 8267914: Remove DeferredObjectToKlass workaround

Changes: https://git.openjdk.java.net/jdk/pull/4242/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4242&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267914
  Stats: 31 lines in 3 files changed: 1 ins; 22 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4242/head:pull/4242

PR: https://git.openjdk.java.net/jdk/pull/4242

From stefank at openjdk.java.net  Fri May 28 11:28:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 11:28:14 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations
Message-ID: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>

The Events classes collect events in a circular buffer that gets dumped into the hs_err files. There are different sections to sort out different types of events. See:

  // A log for internal exception related messages, like internal
  // throws and implicit exceptions.
  static ExceptionsEventLog* _exceptions;

  // Deoptization related messages
  static StringEventLog* _deopt_messages;

  // Redefinition related messages
  static StringEventLog* _redefinitions;

  // Class unloading events
  static UnloadingEventLog* _class_unloading;

There's also a buffer for non-categorized events:

  // A log for generic messages that aren't well categorized.
  static StringEventLog* _messages;

I propose that we create a separate buffer for VMOperations. This will make it easier to debug GC related bugs.

With the proposed patch, the hs_err files will now have a section that looks like this.

VM Operations (20 events):
Event: 0,186 Executing VM operation: HandshakeAllThreads
Event: 0,186 Executing VM operation: HandshakeAllThreads done
Event: 0,230 Executing VM operation: ZMarkStart
Event: 0,230 Executing VM operation: ZMarkStart done
Event: 0,232 Executing VM operation: HandshakeAllThreads
Event: 0,232 Executing VM operation: HandshakeAllThreads done
Event: 0,232 Executing VM operation: HandshakeAllThreads
Event: 0,232 Executing VM operation: HandshakeAllThreads done
Event: 0,232 Executing VM operation: HandshakeAllThreads
Event: 0,233 Executing VM operation: HandshakeAllThreads done
Event: 0,233 Executing VM operation: ZMarkEnd
Event: 0,233 Executing VM operation: ZMarkEnd done
Event: 0,234 Executing VM operation: HandshakeAllThreads
Event: 0,234 Executing VM operation: HandshakeAllThreads done
Event: 0,234 Executing VM operation: ZVerify
Event: 0,234 Executing VM operation: ZVerify done
Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces
Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces done
Event: 0,235 Executing VM operation: ZRelocateStart
Event: 0,235 Executing VM operation: ZRelocateStart done

-------------

Commit messages:
 - 8267920: Create separate Events buffer for VMOperations

Changes: https://git.openjdk.java.net/jdk/pull/4243/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4243&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267920
  Stats: 66 lines in 3 files changed: 46 ins; 3 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4243/head:pull/4243

PR: https://git.openjdk.java.net/jdk/pull/4243

From dholmes at openjdk.java.net  Fri May 28 13:07:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 28 May 2021 13:07:04 GMT
Subject: RFR: JDK-8267916: Make as_CompilerThread consistent with other
 as_*_thread methods
In-Reply-To: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
References: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
Message-ID: <O7BdJQDPkMJrh_34qGnwpwbxOilAPVLKdKSpLo4i6j4=.75b3596e-89be-4840-8c23-72a8450e32e6@github.com>

On Fri, 28 May 2021 08:09:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `as_CompilerThread`. A new file, `compilerThread.inline.hpp`, is created to get around the circular dependency.

Sorry I'm not seeing the need for a new compilerThread.inline.hpp. That isn't making things consistent AFAICS - if we haven't factored out CompilerThread into its own header we shouldn't have compilerThread.inline.hpp.

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4240

From tschatzl at openjdk.java.net  Fri May 28 14:12:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 28 May 2021 14:12:08 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v4]
In-Reply-To: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
Message-ID: <8nhr5kPP_J7KSB8L0ppDo3SL3BfyzYrNPawOUx6r24A=.2d469775-2431-4515-8f44-21da441be68e@github.com>

> Hi all,
> 
>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
> 
>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
> 
> Over time many problems with performance and in particular memory usage have been observed:
> 
> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
> 
> * there is a substantial memory overhead for managing the data structures: examples are
>     * using separate (hash) tables for the three different types of card containers
>     * there is significant unnecessary preallocation of memory for some of the card set containers
>     * Containers store redundant information
> 
> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
> 
> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
> 
> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
> 
> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
> 
> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
> 
> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
> 
> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
> 
> This initial fully working change can be roughly described with the following properties:
> 
> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
> 
> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
> 
> * there are now four different container types and one meta-container type. These four actual containers are:
>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
> 
> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
> 
> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
> 
> Testing: tier1-8 many times, manual and automated perf testing

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  More cleanup after sjohanss comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4116/files
  - new: https://git.openjdk.java.net/jdk/pull/4116/files/c1b83e02..f54c3500

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=02-03

  Stats: 93 lines in 10 files changed: 38 ins; 36 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4116/head:pull/4116

PR: https://git.openjdk.java.net/jdk/pull/4116

From jiefu at openjdk.java.net  Fri May 28 15:05:18 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 28 May 2021 15:05:18 GMT
Subject: RFR: 8267945: ZGC: Revert NUMA changes (JDK-8266217 and JDK-8241354)
 after JDK-8241423
Message-ID: <RNVVDU-VThG6jc6PUn9HAkT0-ggw6fg0VZeRbJec0vA=.71f0b967-1e46-4dec-adba-8b781c5c82fc@github.com>

Hi all,

As discussed here [1], JDK-8266217 and JDK-8241354 make no sense after JDK-8241423.

8266217: ZGC: Improve the -Xlog:gc+init output for NUMA
8241354: ZGC still crashes in containers with NUMA due to get_mempolicy is disabled by default


It would be better to revert the changes.

The patch was prepared like this:

# Revert JDK-8266217
git diff 5ecef01c4a9 5d8c1cc8a05 > r8266217.diff
patch -p1 < r8266217.diff   # patch applied cleanly

# Revert JDK-8241354
git diff 794cefe8f92 23180f848f0 > r8241354.diff
patch -p1 < r8241354.diff   # patch applied cleanly


Testing:
  - hotspot/jtreg/gc/z on Linux/x64 and MacOSX.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/pull/4205#issuecomment-849390011

-------------

Commit messages:
 - 8267945: ZGC: Revert NUMA changes (JDK-8266217 and JDK-8241354) after JDK-8241423

Changes: https://git.openjdk.java.net/jdk/pull/4252/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4252&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267945
  Stats: 56 lines in 6 files changed: 0 ins; 38 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4252/head:pull/4252

PR: https://git.openjdk.java.net/jdk/pull/4252

From eosterlund at openjdk.java.net  Fri May 28 15:28:03 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 May 2021 15:28:03 GMT
Subject: RFR: 8267914: Remove DeferredObjectToKlass workaround
In-Reply-To: <KB3Y4los1LsDtwH_erMi-GQvw8ARkMiShGIWzaZ9yf0=.7cc27017-c52a-496e-a72b-c6adf949adcd@github.com>
References: <KB3Y4los1LsDtwH_erMi-GQvw8ARkMiShGIWzaZ9yf0=.7cc27017-c52a-496e-a72b-c6adf949adcd@github.com>
Message-ID: <sPeyeDyES7Mla9CvemOu-YzhJZ6L6Al1LJ0glL1ARjE=.714491f4-4717-4b87-8e83-fcaa58b5a960@github.com>

On Fri, 28 May 2021 11:13:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In JKD-8229839 we fixed a circular dependency problem between oop.inline.hpp and markWord.inline.hpp.  When JDK-8267464: 
> 'Circular-dependency resilient inline headers' gets integrated, this workaround isn't needed anymore.

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4242

From pliden at openjdk.java.net  Fri May 28 15:33:04 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 28 May 2021 15:33:04 GMT
Subject: RFR: 8267945: ZGC: Revert NUMA changes (JDK-8266217 and
 JDK-8241354) after JDK-8241423
In-Reply-To: <RNVVDU-VThG6jc6PUn9HAkT0-ggw6fg0VZeRbJec0vA=.71f0b967-1e46-4dec-adba-8b781c5c82fc@github.com>
References: <RNVVDU-VThG6jc6PUn9HAkT0-ggw6fg0VZeRbJec0vA=.71f0b967-1e46-4dec-adba-8b781c5c82fc@github.com>
Message-ID: <AATbFZFvBI3EKKR02SOIdnGTyF_D-zyY5aUAnBj4gqg=.fbb5f128-26f9-40d9-ba7e-c1692c4d3284@github.com>

On Fri, 28 May 2021 14:57:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> As discussed here [1], JDK-8266217 and JDK-8241354 make no sense after JDK-8241423.
> 
> 8266217: ZGC: Improve the -Xlog:gc+init output for NUMA
> 8241354: ZGC still crashes in containers with NUMA due to get_mempolicy is disabled by default
> 
> 
> It would be better to revert the changes.
> 
> The patch was prepared like this:
> 
> # Revert JDK-8266217
> git diff 5ecef01c4a9 5d8c1cc8a05 > r8266217.diff
> patch -p1 < r8266217.diff   # patch applied cleanly
> 
> # Revert JDK-8241354
> git diff 794cefe8f92 23180f848f0 > r8241354.diff
> patch -p1 < r8241354.diff   # patch applied cleanly
> 
> 
> Testing:
>   - hotspot/jtreg/gc/z on Linux/x64 and MacOSX.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/pull/4205#issuecomment-849390011

Marked as reviewed by pliden (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4252

From eosterlund at openjdk.java.net  Fri May 28 15:34:06 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 May 2021 15:34:06 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <yCCIz0P3rO1flKmzfXaO2S1svaS9Ru2otSw9H8dh96A=.c01daef3-4897-4828-9b9c-50c8d2ecadc4@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Looks good, but please test with ZGC before integrating.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4217

From mseledtsov at openjdk.java.net  Fri May 28 16:34:03 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 28 May 2021 16:34:03 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: <mpzdKZPZzqgtiXx7x4vOQ26aJGsBNw2MV55TZO0xxQw=.ab6d3d4a-f2bd-46a3-9b0a-19b04c20260e@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).

Looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4241

From kvn at openjdk.java.net  Fri May 28 18:17:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 28 May 2021 18:17:57 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v7]
In-Reply-To: <TWlRdyfYQGw3V7VvZj79_r7HZBH_xpdIas1WlgIR2Gw=.52b9787a-4d85-4109-96ab-b18ab9c61146@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TWlRdyfYQGw3V7VvZj79_r7HZBH_xpdIas1WlgIR2Gw=.52b9787a-4d85-4109-96ab-b18ab9c61146@github.com>
Message-ID: <ZzNXCG-_aGi5K69VSWVlUcjAU3piGMfgV8Id67FoSCs=.bdc435f4-075e-4657-bc8e-0fa3b5cab22a@github.com>

On Fri, 28 May 2021 07:24:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Review kbarrett
>  - Review dholmes
>  - Update HotSpot style guide documents
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Clean up assembler_<cpu>.inline.hpp
>  - 8267464: Circular-dependency resiliant inline headers

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Fri May 28 18:17:21 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 18:17:21 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
Message-ID: <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>

> The Events classes collect events in a circular buffer that gets dumped into the hs_err files. There are different sections to sort out different types of events. See:
> 
>   // A log for internal exception related messages, like internal
>   // throws and implicit exceptions.
>   static ExceptionsEventLog* _exceptions;
> 
>   // Deoptization related messages
>   static StringEventLog* _deopt_messages;
> 
>   // Redefinition related messages
>   static StringEventLog* _redefinitions;
> 
>   // Class unloading events
>   static UnloadingEventLog* _class_unloading;
> 
> There's also a buffer for non-categorized events:
> 
>   // A log for generic messages that aren't well categorized.
>   static StringEventLog* _messages;
> 
> I propose that we create a separate buffer for VMOperations. This will make it easier to debug GC related bugs.
> 
> With the proposed patch, the hs_err files will now have a section that looks like this.
> 
> VM Operations (20 events):
> Event: 0,186 Executing VM operation: HandshakeAllThreads
> Event: 0,186 Executing VM operation: HandshakeAllThreads done
> Event: 0,230 Executing VM operation: ZMarkStart
> Event: 0,230 Executing VM operation: ZMarkStart done
> Event: 0,232 Executing VM operation: HandshakeAllThreads
> Event: 0,232 Executing VM operation: HandshakeAllThreads done
> Event: 0,232 Executing VM operation: HandshakeAllThreads
> Event: 0,232 Executing VM operation: HandshakeAllThreads done
> Event: 0,232 Executing VM operation: HandshakeAllThreads
> Event: 0,233 Executing VM operation: HandshakeAllThreads done
> Event: 0,233 Executing VM operation: ZMarkEnd
> Event: 0,233 Executing VM operation: ZMarkEnd done
> Event: 0,234 Executing VM operation: HandshakeAllThreads
> Event: 0,234 Executing VM operation: HandshakeAllThreads done
> Event: 0,234 Executing VM operation: ZVerify
> Event: 0,234 Executing VM operation: ZVerify done
> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 0,235 Executing VM operation: ZRelocateStart
> Event: 0,235 Executing VM operation: ZRelocateStart done

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review coleenp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4243/files
  - new: https://git.openjdk.java.net/jdk/pull/4243/files/668d5fdb..1d22bd02

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4243&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4243&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4243/head:pull/4243

PR: https://git.openjdk.java.net/jdk/pull/4243

From coleenp at openjdk.java.net  Fri May 28 18:17:45 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 28 May 2021 18:17:45 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
Message-ID: <kkqCqioGJVlZr02C-lho6as94zFVlZYw7-Mt7CnuPHQ=.af634980-209a-46d7-b6d6-44d75104d61d@github.com>

On Fri, 28 May 2021 17:47:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The Events classes collect events in a circular buffer that gets dumped into the hs_err files. There are different sections to sort out different types of events. See:
>> 
>>   // A log for internal exception related messages, like internal
>>   // throws and implicit exceptions.
>>   static ExceptionsEventLog* _exceptions;
>> 
>>   // Deoptization related messages
>>   static StringEventLog* _deopt_messages;
>> 
>>   // Redefinition related messages
>>   static StringEventLog* _redefinitions;
>> 
>>   // Class unloading events
>>   static UnloadingEventLog* _class_unloading;
>> 
>> There's also a buffer for non-categorized events:
>> 
>>   // A log for generic messages that aren't well categorized.
>>   static StringEventLog* _messages;
>> 
>> I propose that we create a separate buffer for VMOperations. This will make it easier to debug GC related bugs.
>> 
>> With the proposed patch, the hs_err files will now have a section that looks like this.
>> 
>> VM Operations (20 events):
>> Event: 0,186 Executing VM operation: HandshakeAllThreads
>> Event: 0,186 Executing VM operation: HandshakeAllThreads done
>> Event: 0,230 Executing VM operation: ZMarkStart
>> Event: 0,230 Executing VM operation: ZMarkStart done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,232 Executing VM operation: HandshakeAllThreads done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,232 Executing VM operation: HandshakeAllThreads done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,233 Executing VM operation: HandshakeAllThreads done
>> Event: 0,233 Executing VM operation: ZMarkEnd
>> Event: 0,233 Executing VM operation: ZMarkEnd done
>> Event: 0,234 Executing VM operation: HandshakeAllThreads
>> Event: 0,234 Executing VM operation: HandshakeAllThreads done
>> Event: 0,234 Executing VM operation: ZVerify
>> Event: 0,234 Executing VM operation: ZVerify done
>> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces
>> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces done
>> Event: 0,235 Executing VM operation: ZRelocateStart
>> Event: 0,235 Executing VM operation: ZRelocateStart done
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review coleenp

This looks good. Took a while to figure out why LogFunction was added, but this is helpful.  We might want to separate class loading in the future.

src/hotspot/share/utilities/events.hpp line 471:

> 469: // These end up in the default log.
> 470: typedef EventMarkWithLogFunction<Events::log> EventMark;
> 471: typedef EventMarkWithLogFunction<Events::log_vm_operation> EventMarkVMOperation;

Can you add a comment just above EventMarkVMOperation line 470 like,
// These go to the vm_operation log
For some reason, I read the comment as applying to both instantiations.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4243

From stefank at openjdk.java.net  Fri May 28 18:18:07 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 18:18:07 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <Eu9U09cS1lEPpPFOpFbtnpv-ZUvQYLIxPFHMoMlb-C4=.fec63ba4-36f0-4d50-a0a6-17f24119b551@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
 <kkqCqioGJVlZr02C-lho6as94zFVlZYw7-Mt7CnuPHQ=.af634980-209a-46d7-b6d6-44d75104d61d@github.com>
 <Eu9U09cS1lEPpPFOpFbtnpv-ZUvQYLIxPFHMoMlb-C4=.fec63ba4-36f0-4d50-a0a6-17f24119b551@github.com>
Message-ID: <Lcud3nfUS2OPEXeQj5m5al90UcTdFJlgcxeAlsKLe5s=.ca062011-e529-402f-873f-ffe6962bea5c@github.com>

On Fri, 28 May 2021 17:47:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/utilities/events.hpp line 471:
>> 
>>> 469: // These end up in the default log.
>>> 470: typedef EventMarkWithLogFunction<Events::log> EventMark;
>>> 471: typedef EventMarkWithLogFunction<Events::log_vm_operation> EventMarkVMOperation;
>> 
>> Can you add a comment just above EventMarkVMOperation line 470 like,
>> // These go to the vm_operation log
>> For some reason, I read the comment as applying to both instantiations.
>
> Makes sense. Pushed.

Thanks for reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4243

From stefank at openjdk.java.net  Fri May 28 18:17:59 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 18:17:59 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <kkqCqioGJVlZr02C-lho6as94zFVlZYw7-Mt7CnuPHQ=.af634980-209a-46d7-b6d6-44d75104d61d@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
 <kkqCqioGJVlZr02C-lho6as94zFVlZYw7-Mt7CnuPHQ=.af634980-209a-46d7-b6d6-44d75104d61d@github.com>
Message-ID: <Eu9U09cS1lEPpPFOpFbtnpv-ZUvQYLIxPFHMoMlb-C4=.fec63ba4-36f0-4d50-a0a6-17f24119b551@github.com>

On Fri, 28 May 2021 17:11:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review coleenp
>
> src/hotspot/share/utilities/events.hpp line 471:
> 
>> 469: // These end up in the default log.
>> 470: typedef EventMarkWithLogFunction<Events::log> EventMark;
>> 471: typedef EventMarkWithLogFunction<Events::log_vm_operation> EventMarkVMOperation;
> 
> Can you add a comment just above EventMarkVMOperation line 470 like,
> // These go to the vm_operation log
> For some reason, I read the comment as applying to both instantiations.

Makes sense. Pushed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4243

From ayang at openjdk.java.net  Fri May 28 19:27:23 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 May 2021 19:27:23 GMT
Subject: RFR: JDK-8267916: Make as_CompilerThread consistent with other
 as_*_thread methods
In-Reply-To: <O7BdJQDPkMJrh_34qGnwpwbxOilAPVLKdKSpLo4i6j4=.75b3596e-89be-4840-8c23-72a8450e32e6@github.com>
References: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
 <O7BdJQDPkMJrh_34qGnwpwbxOilAPVLKdKSpLo4i6j4=.75b3596e-89be-4840-8c23-72a8450e32e6@github.com>
Message-ID: <2IK1x2V3euinl7v1QaeYvAKsEjFh0hAL7mhS5oXJ9q4=.8364ed17-a9be-4b1f-937b-84b677bd1bc6@github.com>

On Fri, 28 May 2021 13:03:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That isn't making things consistent

It's the renaming and move to `thread.inline.hpp` (two points covered in the ticket description) that is supposed to make it more consistent. The creation of `compilerThread.inline.hpp` is just to work around the circular dependency, `CompilerThread::current()` in `compilerThread.hpp` calls `JavaThread::as_CompilerThread` (in `thread.inline.hpp` after the move).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4240

From dholmes at openjdk.java.net  Fri May 28 22:37:20 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 28 May 2021 22:37:20 GMT
Subject: RFR: JDK-8267916: Make as_CompilerThread consistent with other
 as_*_thread methods
In-Reply-To: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
References: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
Message-ID: <TRl--Sy-YMOJM4HKUtCYMD-bNtcYzK4_4LT0CVh4vso=.7c2ab804-f4ea-4074-91df-75e9a26a9084@github.com>

On Fri, 28 May 2021 08:09:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `as_CompilerThread`. A new file, `compilerThread.inline.hpp`, is created to get around the circular dependency.

Sorry I looked at this too late at night:

>  if we haven't factored out CompilerThread into its own header

but we do of course have that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4240

From kbarrett at openjdk.java.net  Fri May 28 23:29:17 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 28 May 2021 23:29:17 GMT
Subject: RFR: JDK-8267916: Make as_CompilerThread consistent with other
 as_*_thread methods
In-Reply-To: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
References: <WAMvbc4ZOkP1-w1jR9ERelCR6aX_FAGQsuTOzMpkXdc=.2f27e5d6-92ca-4f05-9ae9-78a57f0442f4@github.com>
Message-ID: <hOqdno0GO_4I_Uep_MBJl3KAfd29rm9jJtZHFOm1tIM=.d4cc7f44-a53a-4045-8cc3-ea54bdf394f3@github.com>

On Fri, 28 May 2021 08:09:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `as_CompilerThread`. A new file, `compilerThread.inline.hpp`, is created to get around the circular dependency.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/ci/ciEnv.hpp line 34:

> 32: #include "code/dependencies.hpp"
> 33: #include "code/exceptionHandlerTable.hpp"
> 34: #include "compiler/compilerThread.inline.hpp"

Including .inline.hpp by a .hpp is not allowed.

src/hotspot/share/compiler/compilerThread.inline.hpp line 29:

> 27: 
> 28: #include "runtime/thread.inline.hpp"
> 29: #include "compiler/compilerThread.hpp"

This include order is inconsistent with JDK-8267464.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4240

From jiefu at openjdk.java.net  Sat May 29 02:30:20 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 29 May 2021 02:30:20 GMT
Subject: RFR: 8267945: ZGC: Revert NUMA changes (JDK-8266217 and
 JDK-8241354) after JDK-8241423
In-Reply-To: <AATbFZFvBI3EKKR02SOIdnGTyF_D-zyY5aUAnBj4gqg=.fbb5f128-26f9-40d9-ba7e-c1692c4d3284@github.com>
References: <RNVVDU-VThG6jc6PUn9HAkT0-ggw6fg0VZeRbJec0vA=.71f0b967-1e46-4dec-adba-8b781c5c82fc@github.com>
 <AATbFZFvBI3EKKR02SOIdnGTyF_D-zyY5aUAnBj4gqg=.fbb5f128-26f9-40d9-ba7e-c1692c4d3284@github.com>
Message-ID: <-9p3daDp9s0W90UlxVhK0op4P0Rqg0TxTMiF_xrRRtA=.14ede697-ab8d-43b1-9338-efe742431934@github.com>

On Fri, 28 May 2021 15:30:36 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Hi all,
>> 
>> As discussed here [1], JDK-8266217 and JDK-8241354 make no sense after JDK-8241423.
>> 
>> 8266217: ZGC: Improve the -Xlog:gc+init output for NUMA
>> 8241354: ZGC still crashes in containers with NUMA due to get_mempolicy is disabled by default
>> 
>> 
>> It would be better to revert the changes.
>> 
>> The patch was prepared like this:
>> 
>> # Revert JDK-8266217
>> git diff 5ecef01c4a9 5d8c1cc8a05 > r8266217.diff
>> patch -p1 < r8266217.diff   # patch applied cleanly
>> 
>> # Revert JDK-8241354
>> git diff 794cefe8f92 23180f848f0 > r8241354.diff
>> patch -p1 < r8241354.diff   # patch applied cleanly
>> 
>> 
>> Testing:
>>   - hotspot/jtreg/gc/z on Linux/x64 and MacOSX.
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/pull/4205#issuecomment-849390011
>
> Marked as reviewed by pliden (Reviewer).

Thanks @pliden .
Will push it on Monday if there is no objection.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4252

From jiefu at openjdk.java.net  Sun May 30 23:07:23 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 30 May 2021 23:07:23 GMT
Subject: Integrated: 8267945: ZGC: Revert NUMA changes (JDK-8266217 and
 JDK-8241354) after JDK-8241423
In-Reply-To: <RNVVDU-VThG6jc6PUn9HAkT0-ggw6fg0VZeRbJec0vA=.71f0b967-1e46-4dec-adba-8b781c5c82fc@github.com>
References: <RNVVDU-VThG6jc6PUn9HAkT0-ggw6fg0VZeRbJec0vA=.71f0b967-1e46-4dec-adba-8b781c5c82fc@github.com>
Message-ID: <hgdAlTNTtBarsl-zpxD967ns9zT3Nr6G698Bd9fiJVY=.4476dbad-ac4c-4d54-b24d-c64981721649@github.com>

On Fri, 28 May 2021 14:57:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> As discussed here [1], JDK-8266217 and JDK-8241354 make no sense after JDK-8241423.
> 
> 8266217: ZGC: Improve the -Xlog:gc+init output for NUMA
> 8241354: ZGC still crashes in containers with NUMA due to get_mempolicy is disabled by default
> 
> 
> It would be better to revert the changes.
> 
> The patch was prepared like this:
> 
> # Revert JDK-8266217
> git diff 5ecef01c4a9 5d8c1cc8a05 > r8266217.diff
> patch -p1 < r8266217.diff   # patch applied cleanly
> 
> # Revert JDK-8241354
> git diff 794cefe8f92 23180f848f0 > r8241354.diff
> patch -p1 < r8241354.diff   # patch applied cleanly
> 
> 
> Testing:
>   - hotspot/jtreg/gc/z on Linux/x64 and MacOSX.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/pull/4205#issuecomment-849390011

This pull request has now been integrated.

Changeset: 9031477f
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9031477f275a2ecab4167b5367a25731e5e14c2a
Stats:     56 lines in 6 files changed: 0 ins; 38 del; 18 mod

8267945: ZGC: Revert NUMA changes (JDK-8266217 and JDK-8241354) after JDK-8241423

Reviewed-by: pliden

-------------

PR: https://git.openjdk.java.net/jdk/pull/4252

From dholmes at openjdk.java.net  Mon May 31 05:31:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 31 May 2021 05:31:27 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
Message-ID: <JZYnlOcghtZiKpj8I68rVay2s22I6prMdi0dozRlOgc=.cb8cf76f-05d7-41b5-94c8-da349639af3a@github.com>

On Fri, 28 May 2021 18:17:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The Events classes collect events in a circular buffer that gets dumped into the hs_err files. There are different sections to sort out different types of events. See:
>> 
>>   // A log for internal exception related messages, like internal
>>   // throws and implicit exceptions.
>>   static ExceptionsEventLog* _exceptions;
>> 
>>   // Deoptization related messages
>>   static StringEventLog* _deopt_messages;
>> 
>>   // Redefinition related messages
>>   static StringEventLog* _redefinitions;
>> 
>>   // Class unloading events
>>   static UnloadingEventLog* _class_unloading;
>> 
>> There's also a buffer for non-categorized events:
>> 
>>   // A log for generic messages that aren't well categorized.
>>   static StringEventLog* _messages;
>> 
>> I propose that we create a separate buffer for VMOperations. This will make it easier to debug GC related bugs.
>> 
>> With the proposed patch, the hs_err files will now have a section that looks like this.
>> 
>> VM Operations (20 events):
>> Event: 0,186 Executing VM operation: HandshakeAllThreads
>> Event: 0,186 Executing VM operation: HandshakeAllThreads done
>> Event: 0,230 Executing VM operation: ZMarkStart
>> Event: 0,230 Executing VM operation: ZMarkStart done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,232 Executing VM operation: HandshakeAllThreads done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,232 Executing VM operation: HandshakeAllThreads done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,233 Executing VM operation: HandshakeAllThreads done
>> Event: 0,233 Executing VM operation: ZMarkEnd
>> Event: 0,233 Executing VM operation: ZMarkEnd done
>> Event: 0,234 Executing VM operation: HandshakeAllThreads
>> Event: 0,234 Executing VM operation: HandshakeAllThreads done
>> Event: 0,234 Executing VM operation: ZVerify
>> Event: 0,234 Executing VM operation: ZVerify done
>> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces
>> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces done
>> Event: 0,235 Executing VM operation: ZRelocateStart
>> Event: 0,235 Executing VM operation: ZRelocateStart done
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review coleenp

Hi Stefan,

Adding the new event buffer itself seems fine.

Unlike Coleen I can't figure out why you added LogFunction and the new template classes.  :) I can't tell if this was necessary or you just preferred to re-do the specialization mechanism. ??

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4243

From ogatak at openjdk.java.net  Mon May 31 06:02:34 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Mon, 31 May 2021 06:02:34 GMT
Subject: RFR: 8267968: [PPC64] Use prefixed load and addi instructions for
 better perfromance in POWER10
Message-ID: <y9jf9APYUuwHJGDwYxJsADE3SP_roYktxCbXciLgsd4=.56a8512f-4f97-4bc3-a237-8facce36ed24@github.com>

The POWER10 processor supports prefixed load and addi instructions that have larger displacement field of up to 34-bits. We can reduce instruction cycles to load constant from TOC and load an immediate value to a register.

Assembler::{load|add}_const_optimized() and LoadCon[LPFD]Nodes are modified to use prefixed instructions, with fixing other functions that are affected by this change.

I ran jtreg test on both POWER10 and POWER8 machines by using "make test-tier1" and verified no additional fails by this change. I also ran DaCapo, Renaissance, and SPECjbb2015 on both of them and verified they run successfully.

-------------

Commit messages:
 - Fix whitespace and copy right
 - Use prefixed load and addi in more places

Changes: https://git.openjdk.java.net/jdk/pull/4267/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4267&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267968
  Stats: 463 lines in 5 files changed: 332 ins; 26 del; 105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4267.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4267/head:pull/4267

PR: https://git.openjdk.java.net/jdk/pull/4267

From stefank at openjdk.java.net  Mon May 31 06:44:45 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 06:44:45 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v8]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <h2kGJHrmJJW7MWGbxj2OBWvKfOpU3xBrLhkF3rp0ABA=.d5b055ef-8ee5-49e4-9164-2ffc26d3d2aa@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Review kbarrett
 - Review dholmes
 - Update HotSpot style guide documents
 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Clean up assembler_<cpu>.inline.hpp
 - 8267464: Circular-dependency resiliant inline headers

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=07
  Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 31 08:59:22 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 08:59:22 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <JZYnlOcghtZiKpj8I68rVay2s22I6prMdi0dozRlOgc=.cb8cf76f-05d7-41b5-94c8-da349639af3a@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
 <JZYnlOcghtZiKpj8I68rVay2s22I6prMdi0dozRlOgc=.cb8cf76f-05d7-41b5-94c8-da349639af3a@github.com>
Message-ID: <perlL_Sj8N-s9llGTsuYvMEjXsydNvhAoqMyqSPRJQg=.9b7559dd-8466-472e-8011-4b1f4878d252@github.com>

On Mon, 31 May 2021 05:28:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Stefan,
> 
> Adding the new event buffer itself seems fine.
> 
> Unlike Coleen I can't figure out why you added LogFunction and the new template classes. :) I can't tell if this was necessary or you just preferred to re-do the specialization mechanism. ??
> 
> Thanks,
> David

It was mostly done to not duplicate the code of EventMark when adding new EventMarkX classes. This can probably be done different ways. I'm open to suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4243

From stefank at openjdk.java.net  Mon May 31 09:02:32 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 09:02:32 GMT
Subject: Integrated: 8267464: Circular-dependency resilient inline headers
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <H9v57pFhdfqtfzMpdJfBS5Ed3hNBQg6hSM3XuNYmGcY=.3f812158-2b34-418e-8172-5d47af7fa8cc@github.com>

On Thu, 20 May 2021 11:55:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

This pull request has now been integrated.

Changeset: 64f0f689
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64f0f68958a74d4ee34c4b738759fc2278fa8b47
Stats:     490 lines in 242 files changed: 349 ins; 118 del; 23 mod

8267464: Circular-dependency resilient inline headers

Reviewed-by: kbarrett, eosterlund, dholmes, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 31 09:02:31 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 09:02:31 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v8]
In-Reply-To: <h2kGJHrmJJW7MWGbxj2OBWvKfOpU3xBrLhkF3rp0ABA=.d5b055ef-8ee5-49e4-9164-2ffc26d3d2aa@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <h2kGJHrmJJW7MWGbxj2OBWvKfOpU3xBrLhkF3rp0ABA=.d5b055ef-8ee5-49e4-9164-2ffc26d3d2aa@github.com>
Message-ID: <ARWfm7kOPHXGZRJRYsnnJNPFSMMSlCV4Mj85tE9FpTI=.f5a7a6e3-ad08-46e5-8fa8-dbc318a2d24e@github.com>

On Mon, 31 May 2021 06:44:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Review kbarrett
>  - Review dholmes
>  - Update HotSpot style guide documents
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Clean up assembler_<cpu>.inline.hpp
>  - 8267464: Circular-dependency resiliant inline headers

Thanks all for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 31 09:10:33 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 09:10:33 GMT
Subject: RFR: 8267914: Remove DeferredObjectToKlass workaround [v2]
In-Reply-To: <KB3Y4los1LsDtwH_erMi-GQvw8ARkMiShGIWzaZ9yf0=.7cc27017-c52a-496e-a72b-c6adf949adcd@github.com>
References: <KB3Y4los1LsDtwH_erMi-GQvw8ARkMiShGIWzaZ9yf0=.7cc27017-c52a-496e-a72b-c6adf949adcd@github.com>
Message-ID: <WO_CF04sB0IjelU810dCSRcADFr5Gtnazn1wCP3XEqw=.07ea6fff-7f58-4547-9a27-9a992444cbd9@github.com>

> In JKD-8229839 we fixed a circular dependency problem between oop.inline.hpp and markWord.inline.hpp.  When JDK-8267464: 
> 'Circular-dependency resilient inline headers' gets integrated, this workaround isn't needed anymore.

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'origin/master' into 8267914_remove_DeferredObjectToKlass
 - 8267914: Remove DeferredObjectToKlass workaround

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4242/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4242&range=01
  Stats: 31 lines in 3 files changed: 1 ins; 22 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4242/head:pull/4242

PR: https://git.openjdk.java.net/jdk/pull/4242

From tschatzl at openjdk.java.net  Mon May 31 09:41:45 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 May 2021 09:41:45 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v5]
In-Reply-To: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
Message-ID: <y2l5Gx8PXfJXJ5Wvog_lrsBfQy2ZWfa4J82VjLhYOHQ=.cabe5b61-8ce7-4b00-81b4-68c30135387d@github.com>

> Hi all,
> 
>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
> 
>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
> 
> Over time many problems with performance and in particular memory usage have been observed:
> 
> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
> 
> * there is a substantial memory overhead for managing the data structures: examples are
>     * using separate (hash) tables for the three different types of card containers
>     * there is significant unnecessary preallocation of memory for some of the card set containers
>     * Containers store redundant information
> 
> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
> 
> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
> 
> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
> 
> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
> 
> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
> 
> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
> 
> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
> 
> This initial fully working change can be roughly described with the following properties:
> 
> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
> 
> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
> 
> * there are now four different container types and one meta-container type. These four actual containers are:
>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
> 
> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
> 
> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
> 
> Testing: tier1-8 many times, manual and automated perf testing

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' of gh:openjdk/jdk into 8017163-refactor-remembered-set
 - More cleanup after sjohanss comments
 - Rename FOUND
 - Remove prefetching of log buffers
 - iwalulya, sjohanss review
 - Fix 32 bit platforms after premature optimization, implement 64 bit Atomic::sub() via cmpxchg-loop
 - Trailing whitespace fixes
 - Remove unnecessary changes
 - Initial implementation

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4116&range=04
  Stats: 6110 lines in 66 files changed: 4547 ins; 1309 del; 254 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4116/head:pull/4116

PR: https://git.openjdk.java.net/jdk/pull/4116

From sjohanss at openjdk.java.net  Mon May 31 10:25:23 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 31 May 2021 10:25:23 GMT
Subject: RFR: 8017163: G1: Refactor remembered sets [v4]
In-Reply-To: <8nhr5kPP_J7KSB8L0ppDo3SL3BfyzYrNPawOUx6r24A=.2d469775-2431-4515-8f44-21da441be68e@github.com>
References: <wwuBImO9llPdTm_qeNFdbpQzIf3-9M6EaNIODKf2jaE=.e9e04a25-7b0e-4989-900f-fef927691302@github.com>
 <8nhr5kPP_J7KSB8L0ppDo3SL3BfyzYrNPawOUx6r24A=.2d469775-2431-4515-8f44-21da441be68e@github.com>
Message-ID: <hRwEtJXMekHdr92zzy9rCj8R-NgSdSXupLiy_uuJIeE=.9fb7b9c9-cace-4dfc-af26-6e4045c4b71e@github.com>

On Fri, 28 May 2021 14:12:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that significantly refactors the remembered set for more scalability.
>> 
>>  The current G1 remembered set implementation has been designed for use cases and Java heaps and applications from 20 years ago.
>> 
>> Over time many problems with performance and in particular memory usage have been observed:
>> 
>> * adding elements to the lowest tier data structure takes a per-remembered set global lock. Measurements have shown that the applications can wait thousands of seconds acquiring these locks. While the affected threads are in most cases refinement threads so does not directly affect the application, it can still affect the ability of G1 to meet some goals needed for keeping pause times (i.e. amount of cards from the refinement buffers to be merged into the card table and then scanned during gc).
>> 
>> * there is a substantial memory overhead for managing the data structures: examples are
>>     * using separate (hash) tables for the three different types of card containers
>>     * there is significant unnecessary preallocation of memory for some of the card set containers
>>     * Containers store redundant information
>> 
>> * inflexibility when reusing memory: in the current implementation the different containers use different approaches to manage memory. Most use the C heap directly, some the C heap with some internal global memory pool. This in practice makes it very difficult to implement anything other than giving back memory in the collection pause. The corresponding "Free Collection Set" pause can take a significant amount of time because of that.
>> Also memory reuse is limited and preallocating arenas is limited (or would have to be reimplemented multiple times), stressing the C heap allocator.
>> 
>> * inability to support additional use cases: over time interesting ideas (e.g. JDK-8058803) came up for improving performance of remembered set management. Mostly due to redundant information everywhere and completely different handling of various aspects in the containers it is in practice impossible to implement these.
>> 
>> * (partial) inability to give back memory to the OS. While some of the containers use the C heap allocator, and so in some way give back memory, these implementations and handling is different for every container.
>> 
>> * the existing granularity of containers are unbalanced: currently there exist three tiers: "sparse", "fine" and "full". Sparse is an array of cards ranging in the hundreds maybe, "fine" is a bitmap covering a whole region and full is a bit indicating that that region should be scanned completely during GC.
>> 
>> The problem is that there is nothing between "no card at all" and "sparse" and in particular the difference between the capability to hold entries of "sparse" and "fine". I.e. memory usage difference when exceeding a "sparse" array (holding 128 entries at 32M regions, taking ~256 bytes) to fine that is able to hold 65k entries using 8kB is significant.
>> For these reason there is even a dedicated option to stop allocating more "fine" containers and just give up and use "full" instead to avoid excessive memory usage. With extremely bad consequences in pause times.
>> 
>> Over time some of these issues have been fixed or in many cases band-aided, and some of these fixes and ideas were the result of working on this change (e.g. JDK-8262185, JDK-8233919, JDK-8213108).
>> 
>> This change is effectively a rewrite of the Java heap card based part of a region's remembered set.
>> 
>> This initial fully working change can be roughly described with the following properties:
>> 
>> * use a single `ConcurrentHashTable` for the card containers of a given region. The container in use replaced (coarsened) on the fly within the CHT node, completely lock-free. This implements JDK-6949259.
>> 
>> * memory for a given region's remembered set for all containers (and the CHT nodes) is backed by per container type and per remembered set arena style bump-pointer allocation buffers. In this change, in the pause, memory is given back to free lists only. The implementation gives back memory to the OS concurrently to the application. Memory is still managed using the C heap memory manager though, but abstracted away and could be replaced by manual page memory management.
>> 
>> * there are now four different container types and one meta-container type. These four actual containers are:
>>   * inline pointer: the change store a few (3-5) cards in the CHT node directly and uses no extra memory.
>>   * array of cards: similar to the "sparse" container, an array of cards with a configurable amount of entries. However bulk allocation of memory is now managed at a lower level so there is much less waste.
>>   * bitmap: similar to "fine", a bitmap spanning a (sub-)range of memory
>>   * full: same as full, indicating for a (sub-)range of memory that all cards are to be looked at during scan. Similar to inline pointers, this uses no extra memory.
>>   * howl: the Howl container subdivides a given memory range into subranges where any of the other containers describing that sub-range of the heap may be stored in. This is somewhat similar to the idea suggested in JDK-8048504.
>> 
>> * care has been taken to minimize container memory usage, e.g. by not adding redundant information there and in general carefully specify them. They have been designed with future enhancements in mind.
>> 
>> In some benchmarks (where there is significant remembered set memory usage) we are seeing memory reduction to 25% of JDK 16 levels with this change. Garbage collection times are at most as long or shorter than before; most changes affecting pause times have been extracted earlier. Individiual affected phases are generally shorter now.
>> 
>> Testing: tier1-8 many times, manual and automated perf testing
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup after sjohanss comments

A few more comments. Been looking more at the code in my IDE now as well and I think it looks good. I haven't looked closely at the tests yet, but very nice that you added those. I will look at this today or tomorrow. 

A general question about the testing? Have you done any testing with `VerifyRememberedSets` turned on?

src/hotspot/share/gc/g1/g1CardSet.hpp line 77:

> 75: 
> 76:   // Inline pointer configuration
> 77:   bool use_inline_ptr() const { return true; } // Unused for now

Those "Unused for now" functions, should we remove them for now? =)

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 109:

> 107:     G1CardSetOnHeap* _next;
> 108:     uint64_t _ref_count;
> 109:   };

We discussed this a bit offline, would it make sense to have a common parent for this to make it more obvious where the `_next` field is used (`G1CardSetMemoryObject`).

src/hotspot/share/gc/g1/g1RemSet.cpp line 1458:

> 1456: void G1RemSet::print_merge_heap_roots_stats() {
> 1457:   Log(gc, remset) log;
> 1458:   LogStream ls(log.debug());

A more common pattern in the GC-code is to use:

LogTarget(Debug, gc, remset) lt;
if (lt.is_enabled()) {
  LogStream ls(lt);
  ...
} 

So unless something below needs to be called even when not logging I would prefer using this approach. You could of course also use `log.is_debug()` if you prefer to keep this way to create the `LogStream` but wanted to make things conditional. 

Looking a bit more I see there is a pre-existing `Log(gc, remset)`, so feel free to keep using that. In that case the logging is made conditional by caling `log_is_enabled(Trace, gc, remset)`, yet another way =)

src/hotspot/share/gc/g1/g1RemSet.cpp line 1526:

> 1524:   LogStream ls(log.debug());
> 1525: 
> 1526:   G1CardSet::print_coarsen_stats(&ls);

Same as above. I think we should make this call conditional and only be done when the logging is enabled.

src/hotspot/share/gc/g1/g1ServiceThread.cpp line 29:

> 27: #include "gc/g1/heapRegion.inline.hpp"
> 28: #include "gc/g1/heapRegionRemSet.inline.hpp"
> 29: #include "gc/shared/suspendibleThreadSet.hpp"

I think all changes to g1ServiceThread.* could be reverted now when you added the state to the new task instead. Adding `is_enqueued()` to not check `next() == NULL` is a good change, but it should be made on its own.

src/hotspot/share/gc/g1/heapRegion.cpp line 622:

> 620:             LogStream ls(log.error());
> 621:             to->rem_set()->print_info(&ls, p);
> 622:           }

Instead of adding this scope, can't we just create the `LogStream` here and the re-use it below?

src/hotspot/share/gc/g1/heapRegionRemSet.hpp line 126:

> 124:       // This correction is necessary because the above includes the second
> 125:       // part.
> 126:       + (sizeof(HeapRegionRemSet) - sizeof(G1CardSet))

Pre-existing, but what do you think about moving/including the comment for this part of the calculation in the function comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4116

From tschatzl at openjdk.java.net  Mon May 31 10:38:18 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 May 2021 10:38:18 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
Message-ID: <ZSEpD6ypvX0ejDF4W6MJVbh-zROPzL7yFDKzTQ5wCLY=.9591247f-0358-4f41-a588-4abcfe275543@github.com>

On Fri, 28 May 2021 18:17:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The Events classes collect events in a circular buffer that gets dumped into the hs_err files. There are different sections to sort out different types of events. See:
>> 
>>   // A log for internal exception related messages, like internal
>>   // throws and implicit exceptions.
>>   static ExceptionsEventLog* _exceptions;
>> 
>>   // Deoptization related messages
>>   static StringEventLog* _deopt_messages;
>> 
>>   // Redefinition related messages
>>   static StringEventLog* _redefinitions;
>> 
>>   // Class unloading events
>>   static UnloadingEventLog* _class_unloading;
>> 
>> There's also a buffer for non-categorized events:
>> 
>>   // A log for generic messages that aren't well categorized.
>>   static StringEventLog* _messages;
>> 
>> I propose that we create a separate buffer for VMOperations. This will make it easier to debug GC related bugs.
>> 
>> With the proposed patch, the hs_err files will now have a section that looks like this.
>> 
>> VM Operations (20 events):
>> Event: 0,186 Executing VM operation: HandshakeAllThreads
>> Event: 0,186 Executing VM operation: HandshakeAllThreads done
>> Event: 0,230 Executing VM operation: ZMarkStart
>> Event: 0,230 Executing VM operation: ZMarkStart done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,232 Executing VM operation: HandshakeAllThreads done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,232 Executing VM operation: HandshakeAllThreads done
>> Event: 0,232 Executing VM operation: HandshakeAllThreads
>> Event: 0,233 Executing VM operation: HandshakeAllThreads done
>> Event: 0,233 Executing VM operation: ZMarkEnd
>> Event: 0,233 Executing VM operation: ZMarkEnd done
>> Event: 0,234 Executing VM operation: HandshakeAllThreads
>> Event: 0,234 Executing VM operation: HandshakeAllThreads done
>> Event: 0,234 Executing VM operation: ZVerify
>> Event: 0,234 Executing VM operation: ZVerify done
>> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces
>> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces done
>> Event: 0,235 Executing VM operation: ZRelocateStart
>> Event: 0,235 Executing VM operation: ZRelocateStart done
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review coleenp

Lgtm, feel free to ignore the comment on the protected constructor/NONCOPYABLE.

src/hotspot/share/utilities/events.hpp line 443:

> 441:  public:
> 442:   EventMarkBase(EventLogFunction log_function);
> 443: };

The `EventMarkBase` constructor could be protected as well, and the class `NONCOPYABLE`.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4243

From stefank at openjdk.java.net  Mon May 31 11:17:44 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 11:17:44 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v3]
In-Reply-To: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
Message-ID: <dq1XC9jpY04rnuuoKseFCTBHPwTa4pORm7Lt_6C-9LA=.7d288341-ce99-408e-a459-895bbc48dfd2@github.com>

> The Events classes collect events in a circular buffer that gets dumped into the hs_err files. There are different sections to sort out different types of events. See:
> 
>   // A log for internal exception related messages, like internal
>   // throws and implicit exceptions.
>   static ExceptionsEventLog* _exceptions;
> 
>   // Deoptization related messages
>   static StringEventLog* _deopt_messages;
> 
>   // Redefinition related messages
>   static StringEventLog* _redefinitions;
> 
>   // Class unloading events
>   static UnloadingEventLog* _class_unloading;
> 
> There's also a buffer for non-categorized events:
> 
>   // A log for generic messages that aren't well categorized.
>   static StringEventLog* _messages;
> 
> I propose that we create a separate buffer for VMOperations. This will make it easier to debug GC related bugs.
> 
> With the proposed patch, the hs_err files will now have a section that looks like this.
> 
> VM Operations (20 events):
> Event: 0,186 Executing VM operation: HandshakeAllThreads
> Event: 0,186 Executing VM operation: HandshakeAllThreads done
> Event: 0,230 Executing VM operation: ZMarkStart
> Event: 0,230 Executing VM operation: ZMarkStart done
> Event: 0,232 Executing VM operation: HandshakeAllThreads
> Event: 0,232 Executing VM operation: HandshakeAllThreads done
> Event: 0,232 Executing VM operation: HandshakeAllThreads
> Event: 0,232 Executing VM operation: HandshakeAllThreads done
> Event: 0,232 Executing VM operation: HandshakeAllThreads
> Event: 0,233 Executing VM operation: HandshakeAllThreads done
> Event: 0,233 Executing VM operation: ZMarkEnd
> Event: 0,233 Executing VM operation: ZMarkEnd done
> Event: 0,234 Executing VM operation: HandshakeAllThreads
> Event: 0,234 Executing VM operation: HandshakeAllThreads done
> Event: 0,234 Executing VM operation: ZVerify
> Event: 0,234 Executing VM operation: ZVerify done
> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 0,234 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 0,235 Executing VM operation: ZRelocateStart
> Event: 0,235 Executing VM operation: ZRelocateStart done

Stefan Karlsson 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:

 - Review tschatzl
 - Merge remote-tracking branch 'origin/master' into 8267914_events_vmoperations
 - Review coleenp
 - 8267920: Create separate Events buffer for VMOperations

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4243/files
  - new: https://git.openjdk.java.net/jdk/pull/4243/files/1d22bd02..601310ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4243&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4243&range=01-02

  Stats: 1484 lines in 53 files changed: 499 ins; 717 del; 268 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4243/head:pull/4243

PR: https://git.openjdk.java.net/jdk/pull/4243

From stefank at openjdk.java.net  Mon May 31 11:17:45 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 11:17:45 GMT
Subject: RFR: 8267920: Create separate Events buffer for VMOperations [v2]
In-Reply-To: <ZSEpD6ypvX0ejDF4W6MJVbh-zROPzL7yFDKzTQ5wCLY=.9591247f-0358-4f41-a588-4abcfe275543@github.com>
References: <fE7bXv7IP3K1vK0UCJJqV22B70U_-9b1zsE0z5DVqn4=.fee48de4-a0d2-4e72-947a-b4324c7a3e39@github.com>
 <PuS_mphzfATWnrGVsmEFeGpzUK56XHHfJSgFeqhUoKg=.88e406d2-217a-4a45-be5f-c408b69e6ac8@github.com>
 <ZSEpD6ypvX0ejDF4W6MJVbh-zROPzL7yFDKzTQ5wCLY=.9591247f-0358-4f41-a588-4abcfe275543@github.com>
Message-ID: <PIScf78rF6Xdd7F62Fo20zXeeKoT08BrHafYKFMqHHE=.fb2ea2f2-ab71-481e-91f5-abd6ca567e49@github.com>

On Mon, 31 May 2021 10:34:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review coleenp
>
> src/hotspot/share/utilities/events.hpp line 443:
> 
>> 441:  public:
>> 442:   EventMarkBase(EventLogFunction log_function);
>> 443: };
> 
> The `EventMarkBase` constructor could be protected as well, and the class `NONCOPYABLE`.

Will update. Thanks for reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4243

From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  default behavior reverted to allow

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <TdTmyQQ8Wnh6Ko6yk3xYGN-eN8CCaUiw_W6bh9WbOTc=.8388e5dc-6cf8-4215-be1e-4b98eadb6d4c@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From chagedorn at openjdk.java.net  Mon May 31 15:43:41 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 31 May 2021 15:43:41 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v10]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <wGect1vMYI3psljDtEYZ8OfQmBmTwQmm452-1gfuIKk=.d72bb3f1-6fca-4527-8624-5e56aa2f0723@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn 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 24 additional commits since the last revision:

 - Fix Compiler and CompLevel ANY and fix tests after merge
 - Merge branch 'master' into JDK-8254129
 - Splitting classes into subpackages and updating README accordingly, fix bug with new line matching in lookbehind on Windows
 - Fix package names and fixing internal tests, examples and README file accordingly
 - Move framework to test/hotspot/jtreg/compiler/lib and tests to test/hotspot/jtreg/testlibrary_tests/compiler/lib/ir_framework
 - Remove TestFramework: both runWithScenarios, both runWithHelperClasses, and one runWithFlags method to make interface cleaner/simpler, update internal tests accordingly
 - Minor improvements, comment fixes, and test fixes
 - Rename TestFrameworkPrepareFlags -> FlagVM and rename TestFrameworkExecution -> TestVM
 - Apply review comments: Extract Test classes into own files, extract Flag and Test VM processes into own class, replace socket-based flag VM communication with file-based and clean up socket usage of test VM, fix useless processing of hotspot-pid files if no IR rules are applied
 - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/43104827...c35c658c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/4424e01f..c35c658c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=08-09

  Stats: 678487 lines in 8333 files changed: 92327 ins; 561494 del; 24666 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon May 31 15:43:42 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 31 May 2021 15:43:42 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v9]
In-Reply-To: <PqaKCsAvDdmFfg1vcTvjG5DEjwjajKWD0J1PRPzbYLA=.81406790-be0c-41dd-b278-6af3fb52157e@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <PqaKCsAvDdmFfg1vcTvjG5DEjwjajKWD0J1PRPzbYLA=.81406790-be0c-41dd-b278-6af3fb52157e@github.com>
Message-ID: <J2pgEt02Bnyp_1hacZEzBeuWpVBszRE7rAUBoqCSHYs=.d5b1b595-e4c0-4425-a06f-6df2367d8c9d@github.com>

On Tue, 4 May 2021 15:53:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Splitting classes into subpackages and updating README accordingly, fix bug with new line matching in lookbehind on Windows
>  - Fix package names and fixing internal tests, examples and README file accordingly
>  - Move framework to test/hotspot/jtreg/compiler/lib and tests to test/hotspot/jtreg/testlibrary_tests/compiler/lib/ir_framework

I'm back to work and "reopen" this PR again.

@TobiHartmann Good point! I merged the master branch and fixed this to `-1` together with some other test failures that emerged after the update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From luhenry at openjdk.java.net  Mon May 31 16:13:29 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Mon, 31 May 2021 16:13:29 GMT
Subject: RFR: JDK-8267985: Allow AsyncGetCallTrace and JFR to walk a stub frame
Message-ID: <Fo6xu2wZ3ixLA9tW7jsVmqw_zb5V8BPRQ5C-MienVQ0=.8290ec51-ffd0-4c1c-b74b-3b8cf8eeed4b@github.com>

When the signal sent for AsyncGetCallTrace or JFR would land on a stub
(like arraycopy), it wouldn't be able to detect the sender (caller)
frame because `_cb->frame_size() == 0`.

Because we fully control how the prolog and epilog of stub code is
generated, we know there are two cases:
1. A stack frame is allocated via macroAssembler->enter(), and consists
in `push rbp; mov rsp, rbp;`.
2. No stack frames are allocated and rbp is left unchanged and rsp is
decremented with the `call` instruction that push the return `pc` on the
stack.

For case 1., we can easily know the sender frame by simply looking at
rbp, especially since we know that all stubs preserver the frame pointer
(on x86 at least).

For case 2., we end up returning the sender's sender, but that already
gives us more information than what we have today.

-------------

Commit messages:
 - JDK-8267985: Allow AsyncGetCallTrace and JFR to walk a stub frame

Changes: https://git.openjdk.java.net/jdk/pull/4274/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4274&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267985
  Stats: 41 lines in 1 file changed: 31 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4274/head:pull/4274

PR: https://git.openjdk.java.net/jdk/pull/4274

From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073