Re: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...")

[Jaikiran Pai]

Thank you all for the real quick fix for these 2 issues.

In the context of Quarkus project, trying to get a decent workaround to
get past these issues across all prominent Java versions (and OS) was
starting to get a bit out of hand. But with this fixed consistently
within in the JDK now, it's much more comforting that the workarounds
that we have put in place in Quarkus won't need to last too long.

-Jaikiran

On 10/12/19 1:47 AM, Jonathan Gibbons wrote:
> I note that javac now uses the same definition of tryResolveFile in
> its handling of Class-Path manifest entries, and so the behavior for
> the compiler and runtime should now be aligned.
>
> -- Jon
>
>
> On 12/09/2019 12:10 PM, Brent Christian wrote:
>> Hi,
>>
>> As discussed[1] last month on this alias, JAR Class-Path entries[2]
>> that encode an absolute Windows path (including a drive letter, so
>> e.g. "/C:/path/to/file.jar") are ignored as of 8211941.
>>
>> Such entries are legal relative URLs, and should not be ignored.
>> Please review my fix to correct this.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8235361
>> Webrev:
>> http://cr.openjdk.java.net/~bchristi/8235361/webrev06-open/
>>
>> Thanks,
>> -Brent
>>
>> 1.
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063491.html
>>
>> 2.
>> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute
>>
>

Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64

[Vladimir Kozlov]

Testing results are good after fixing the typo.

We should consider implementing this intrinsic in Graal too. We have to upload 
AOT and Graal test changes anyway.

Thanks,
Vladimir

On 12/20/19 3:47 PM, Vladimir Kozlov wrote:

Hi Smita,

You have typo (should be supports_vbmi2):

src/hotspot/cpu/x86/assembler_x86.cpp:6547:22: error: 'support_vbmi2' is not a 
member of 'VM_Version'
     assert(VM_Version::support_vbmi2(), "requires vbmi2");
    ^

Debug build failed. I am retesting with local fix.

Regards,
Vladimir K

On 12/20/19 2:19 PM, Vladimir Kozlov wrote:

We should have added core-libs to review since you modified BigInteger.java.

webrev02 looks good to me. Let me test it.

Thanks,
Vladimir

On 12/20/19 1:52 PM, Kamath, Smita wrote:

Hi Vladimir,

Thank you for reviewing the code. I have updated the code as per your 
recommendations ( please look at the email below).
Link to the updated webrev: 
https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/

Regards,
Smita

-Original Message-
From: Vladimir Kozlov 
Sent: Thursday, December 19, 2019 5:17 PM
To: Kamath, Smita 
Cc: Viswanathan, Sandhya ; 'hotspot compiler' 

Subject: Re: RFR(M):8167065: Add intrinsic support for double precision 
shifting on x86_64

We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record 
StubRoutines pointers:

StubRoutines::_bigIntegerRightShiftWorker
StubRoutines::_bigIntegerLeftShiftWorker
Smita>>>done

In the test add an other @run command with default setting (without 
-XX:-TieredCompilation -Xbatch).
Smita>>>done

Thanks,
Vladimir

[1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/

On 12/18/19 6:33 PM, Kamath, Smita wrote:

Hi Vladimir,

I have made the code changes you suggested (please look at the email below).
I have also enabled the intrinsic to run only when VBMI2 feature is available.
The intrinsic shows gains of >1.5x above 4k bit BigInteger.

Webrev link:
https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/

Thanks,
Smita

-Original Message-
From: Vladimir Kozlov 
Sent: Wednesday, December 11, 2019 10:55 AM
To: Kamath, Smita ; 'hotspot compiler'
; Viswanathan, Sandhya

Subject: Re: RFR(M):8167065: Add intrinsic support for double
precision shifting on x86_64

Hi Kamath,

First, general question. What performance you see when VBMI2 instructions are *not* used with your new code vs code 
generated by C2.

What improvement you see when VBMI2 is used. This is to understand if we need 
only VBMI2 version of intrinsic or not.

Second. Sandhya recently pushed 8235510 changes to rollback avx512 code for CRC32 due to performance issues. Does 
you change has any issues on some Intel's CPU too? Should it be excluded on such CPUs?


Third. I would suggest to wait after we fork JDK 14 with this changes. I think it may be too late for 14 because we 
would need test this including performance testing.


In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert.
For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit when UseAVX < 3 ( < avx512). You can also use 
supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in stubGenerator_x86_64.cpp combinations with that.

Smita >>>done

I don't think we need separate flag UseVBMI2 - it could be controlled by UseAVX flag. We don't have flag for VNNI or 
other avx512 instructions subset.

Smita >> removed UseVBMI2 flag

In vm_version_x86.cpp you need to add more %s in print statement for new output.
Smita  >>> done

You need to add @requires vm.compiler2.enabled to new test's commands to run it 
only with C2.
Smita >>> done

You need to add intrinsics to Graal's test to ignore them:

http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal.
vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/gr
aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416
Smita >>>done

Thanks,
Vladimir

On 12/10/19 5:41 PM, Kamath, Smita wrote:

Hi,


As per Intel Architecture Instruction Set Reference [1] VBMI2 Operations will be supported in future Intel ISA. I 
would like to contribute optimizations for BigInteger shift operations using AVX512+VBMI2 instructions. This 
optimization is for x86_64 architecture enabled.


Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065

Link to webrev :
http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/



I ran jtreg test suite with the algorithm on Intel SDE [2] to confirm that encoding and semantics are correctly 
implemented.



[1]
https://software.intel.com/sites/default/files/managed/39/c5/325462-s
d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and vpshldv ->
Vol.
2C 5-471)

[2]
https://software.intel.com/en-us/articles/intel-software-development-
e
mulator


Regards,

Smita Kamath

Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64

[Vladimir Kozlov]

Hi Smita,

You have typo (should be supports_vbmi2):

src/hotspot/cpu/x86/assembler_x86.cpp:6547:22: error: 'support_vbmi2' is not a 
member of 'VM_Version'
assert(VM_Version::support_vbmi2(), "requires vbmi2");
   ^

Debug build failed. I am retesting with local fix.

Regards,
Vladimir K

On 12/20/19 2:19 PM, Vladimir Kozlov wrote:

We should have added core-libs to review since you modified BigInteger.java.

webrev02 looks good to me. Let me test it.

Thanks,
Vladimir

On 12/20/19 1:52 PM, Kamath, Smita wrote:

Hi Vladimir,

Thank you for reviewing the code. I have updated the code as per your 
recommendations ( please look at the email below).
Link to the updated webrev: 
https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/

Regards,
Smita

-Original Message-
From: Vladimir Kozlov 
Sent: Thursday, December 19, 2019 5:17 PM
To: Kamath, Smita 
Cc: Viswanathan, Sandhya ; 'hotspot compiler' 

Subject: Re: RFR(M):8167065: Add intrinsic support for double precision 
shifting on x86_64

We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record 
StubRoutines pointers:

StubRoutines::_bigIntegerRightShiftWorker
StubRoutines::_bigIntegerLeftShiftWorker
Smita>>>done

In the test add an other @run command with default setting (without 
-XX:-TieredCompilation -Xbatch).
Smita>>>done

Thanks,
Vladimir

[1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/

On 12/18/19 6:33 PM, Kamath, Smita wrote:

Hi Vladimir,

I have made the code changes you suggested (please look at the email below).
I have also enabled the intrinsic to run only when VBMI2 feature is available.
The intrinsic shows gains of >1.5x above 4k bit BigInteger.

Webrev link:
https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/

Thanks,
Smita

-Original Message-
From: Vladimir Kozlov 
Sent: Wednesday, December 11, 2019 10:55 AM
To: Kamath, Smita ; 'hotspot compiler'
; Viswanathan, Sandhya

Subject: Re: RFR(M):8167065: Add intrinsic support for double
precision shifting on x86_64

Hi Kamath,

First, general question. What performance you see when VBMI2 instructions are *not* used with your new code vs code 
generated by C2.

What improvement you see when VBMI2 is used. This is to understand if we need 
only VBMI2 version of intrinsic or not.

Second. Sandhya recently pushed 8235510 changes to rollback avx512 code for CRC32 due to performance issues. Does you 
change has any issues on some Intel's CPU too? Should it be excluded on such CPUs?


Third. I would suggest to wait after we fork JDK 14 with this changes. I think it may be too late for 14 because we 
would need test this including performance testing.


In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert.
For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit when UseAVX < 3 ( < avx512). You can also use 
supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in stubGenerator_x86_64.cpp combinations with that.

Smita >>>done

I don't think we need separate flag UseVBMI2 - it could be controlled by UseAVX flag. We don't have flag for VNNI or 
other avx512 instructions subset.

Smita >> removed UseVBMI2 flag

In vm_version_x86.cpp you need to add more %s in print statement for new output.
Smita  >>> done

You need to add @requires vm.compiler2.enabled to new test's commands to run it 
only with C2.
Smita >>> done

You need to add intrinsics to Graal's test to ignore them:

http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal.
vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/gr
aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416
Smita >>>done

Thanks,
Vladimir

On 12/10/19 5:41 PM, Kamath, Smita wrote:

Hi,


As per Intel Architecture Instruction Set Reference [1] VBMI2 Operations will be supported in future Intel ISA. I 
would like to contribute optimizations for BigInteger shift operations using AVX512+VBMI2 instructions. This 
optimization is for x86_64 architecture enabled.


Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065

Link to webrev :
http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/



I ran jtreg test suite with the algorithm on Intel SDE [2] to confirm that encoding and semantics are correctly 
implemented.



[1]
https://software.intel.com/sites/default/files/managed/39/c5/325462-s
d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and vpshldv ->
Vol.
2C 5-471)

[2]
https://software.intel.com/en-us/articles/intel-software-development-
e
mulator


Regards,

Smita Kamath

Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64

[Vladimir Kozlov]

We should have added core-libs to review since you modified BigInteger.java.

webrev02 looks good to me. Let me test it.

Thanks,
Vladimir

On 12/20/19 1:52 PM, Kamath, Smita wrote:

Hi Vladimir,

Thank you for reviewing the code. I have updated the code as per your 
recommendations ( please look at the email below).
Link to the updated webrev: 
https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/

Regards,
Smita

-Original Message-
From: Vladimir Kozlov 
Sent: Thursday, December 19, 2019 5:17 PM
To: Kamath, Smita 
Cc: Viswanathan, Sandhya ; 'hotspot compiler' 

Subject: Re: RFR(M):8167065: Add intrinsic support for double precision 
shifting on x86_64

We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record 
StubRoutines pointers:

StubRoutines::_bigIntegerRightShiftWorker
StubRoutines::_bigIntegerLeftShiftWorker
Smita>>>done

In the test add an other @run command with default setting (without 
-XX:-TieredCompilation -Xbatch).
Smita>>>done

Thanks,
Vladimir

[1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/

On 12/18/19 6:33 PM, Kamath, Smita wrote:

Hi Vladimir,

I have made the code changes you suggested (please look at the email below).
I have also enabled the intrinsic to run only when VBMI2 feature is available.
The intrinsic shows gains of >1.5x above 4k bit BigInteger.

Webrev link:
https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/

Thanks,
Smita

-Original Message-
From: Vladimir Kozlov 
Sent: Wednesday, December 11, 2019 10:55 AM
To: Kamath, Smita ; 'hotspot compiler'
; Viswanathan, Sandhya

Subject: Re: RFR(M):8167065: Add intrinsic support for double
precision shifting on x86_64

Hi Kamath,

First, general question. What performance you see when VBMI2 instructions are 
*not* used with your new code vs code generated by C2.
What improvement you see when VBMI2 is used. This is to understand if we need 
only VBMI2 version of intrinsic or not.

Second. Sandhya recently pushed 8235510 changes to rollback avx512 code for 
CRC32 due to performance issues. Does you change has any issues on some Intel's 
CPU too? Should it be excluded on such CPUs?

Third. I would suggest to wait after we fork JDK 14 with this changes. I think 
it may be too late for 14 because we would need test this including performance 
testing.

In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert.
For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit when UseAVX < 3 ( < 
avx512). You can also use supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in 
stubGenerator_x86_64.cpp combinations with that.
Smita >>>done

I don't think we need separate flag UseVBMI2 - it could be controlled by UseAVX 
flag. We don't have flag for VNNI or other avx512 instructions subset.
Smita >> removed UseVBMI2 flag

In vm_version_x86.cpp you need to add more %s in print statement for new output.
Smita  >>> done

You need to add @requires vm.compiler2.enabled to new test's commands to run it 
only with C2.
Smita >>> done

You need to add intrinsics to Graal's test to ignore them:

http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal.
vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/gr
aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416
Smita >>>done

Thanks,
Vladimir

On 12/10/19 5:41 PM, Kamath, Smita wrote:

Hi,


As per Intel Architecture Instruction Set Reference [1] VBMI2 Operations will 
be supported in future Intel ISA. I would like to contribute optimizations for 
BigInteger shift operations using AVX512+VBMI2 instructions. This optimization 
is for x86_64 architecture enabled.

Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065

Link to webrev :
http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/



I ran jtreg test suite with the algorithm on Intel SDE [2] to confirm that 
encoding and semantics are correctly implemented.


[1]
https://software.intel.com/sites/default/files/managed/39/c5/325462-s
d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and vpshldv ->
Vol.
2C 5-471)

[2]
https://software.intel.com/en-us/articles/intel-software-development-
e
mulator


Regards,

Smita Kamath

[15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols

[naoto . sato]

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8227313

The proposed CSR and changeset are located at:

https://bugs.openjdk.java.net/browse/JDK-8235942
https://cr.openjdk.java.net/~naoto/8227313/webrev.00/

The change introduces the new monetary grouping separator in 
DecimalFormatSymbols, and it is used if a DecimalFormat instance 
designates currency formatting where its pattern includes the currency 
symbol (U+00A5). The change makes use of the CLDR data which provides 
two distinct grouping separators (one for generic, the other for 
currency) in some locales. It also addresses the similar cases for the 
decimal separator.


Naoto

RFR: JDK-8236132: Add missing properties to msi installers

[Alexey Semenyuk]

Please review fix [2] for jpackage bug [1].

Add properties to msi installers to properly display installation 
location and icon of the application in the list of installed applications.


- Alexey

[1] https://bugs.openjdk.java.net/browse/JDK-8236132

[2] http://cr.openjdk.java.net/~asemenyuk/8236132/webrev.00

Re: RFR: JDK-8233578: Document configurable parameters of msi packages

[Andy Herrick]

looks good.

/Andy

On 12/19/2019 8:52 PM, Alexey Semenyuk wrote:

Please review fix [2] for jpackage bug [1].

Comments added to the default WiX source file explaining how the 
default file is expected to be overridden.


- Alexey

[1] https://bugs.openjdk.java.net/browse/JDK-8233578

[2] http://cr.openjdk.java.net/~asemenyuk/8233578/webrev.00

Re: RFR: JDK-8232077: Investigate if default behavior should allow downgrade scenario

[Andy Herrick]

fix looks fine.

/Andy

On 12/19/2019 8:02 PM, Alexey Semenyuk wrote:

Please review fix [2] for jpackage bug [1].

The fix changes the default setting for Windows installers to allow 
downgrades.


- Alexey

[1] https://bugs.openjdk.java.net/browse/JDK-8232077

[2] http://cr.openjdk.java.net/~asemenyuk/8232077/webrev.00

Re: RFR 8234362: k_standard.c is not needed and should be removed

[Florian Weimer]

* Florian Weimer:

> * Florian Weimer:
>
>> __kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
>> is built for _IEEE_LIBM targets as well, but it appears superfluous
>> there.
>>
>> In noticed this because GCC 10 flags an uninitialized variable in this
>> code:
>>
>> …/src/java.base/share/native/libfdlibm/k_standard.c: In function 
>> '__j__kernel_standard':
>> …/src/java.base/share/native/libfdlibm/k_standard.c:743:19: error: 
>> 'exc.retval' may be used uninitialized in this function 
>> [-Werror=maybe-uninitialized]
>>   743 | return exc.retval;
>>   |~~~^~~
>>
>> Rather than debating whether this warning is reasonableor not, I would
>> suggest to #ifdef out this code for _IEEE_LIBM targets (are there any
>> else left?).
>
> I think the file should just be removed.
>
> Bug: 
> Webrev: 
>
> As usual, I'll need a sponsor for this.

Is there anything I can do to make this patch more palatable?

Thanks,
Florian

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

[Severin Gehwolf]

Hi Bob,

Sorry for the delay to get this updated.

Changes done in this latest webrev:

   1. Rebased on top of 8226575: OperatingSystemMXBean should be made
  container aware. File read ops now use privileged code.
   2. Warning for mixed cgroup controllers and returning null for metrics.
   3. Added implementations for getBlkIOServiceCount() and
  getBlkIOServiced() using sum of rios/wios and rbytes/wbytes across
  devices. Added impl for getTcpMemoryUsage()
   4. Returning -2 for not supported (if the metric would return long).
  boolean metrics now return Boolean and null if not supported. Same
  for array return types. null if not supported for symmetry.
   5. -XshowSettings:system output has been updated to return "N/A" for
  when a metric is not available. E.g. "Kernel OOM killer enabled"
  Boolean.
   6. Tests have been updated to reflect this.

webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/06/webrev/
incremental webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/06-incremental/webrev/

Testing: Docker tests and podman testing on cgroupsv2. I'll run it
through jdk/submit as well.

Hopefully this can get pushed with 8230305 early on in the jdk 15 cycle
:)

A couple of more inline comments below.

On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote:
> Sorry for the delay in responding.  See comments below:
> 
> > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf  wrote:
> > 
> > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Could I please get reviews of these core-libs, Linux-only, changes to
> > > the Metrics subsystem? This patch implements cgroupv2 support for
> > > Metrics which are currently cgroupv1-only. Fedora 31 switched to
> > > cgroupv2 by default so it's time to get OpenJDK recognize it.
> > > 
> > > Note that a couple of metrics are no longer supported with cgroupv2.
> > > Most notably (not an exhaustive list, though):
> > > 
> > > Metrics.getKernel*() family of methods.
> > > Metrics.getTcp*() family of methods.
> > > Metrics.getBlkIO*() family of methods.
> > > Metrics.isMemoryOOMKillEnabled()
> > > 
> > > A couple of open questions with regards to that:
> > > 
> > > 1)
> > > Most API docs of Metrics make no distiction between "unlimited" and
> > > "not supported", both returning -1 for longs, for example. This is a
> > > problem, because output of "java -XshowSettings:system -version" will
> > > not distinguish between unlimited and not supported metrics. Would it
> > > be acceptable to change the API to distinguish those cases so that
> > > LauncherHelper could display them appropriately?
> > > 
> > > 2)
> > > How should we deal with "not supported" for booleans/arrays, etc.?
> > > Would it make sense to return record objects from the Metrics API so
> > > that this could be dealt with? E.g.
> > > 
> > > Metrics m = ...
> > > MetricResult result = m.getCpuSetCpus();
> > > switch(result.getType()) {
> > >   case NOT_SUPPORTED: /* do something */; break;
> > >   case SUPPORTED: int[] val = result.get(); break;
> > >   ... 
> > > }
> > > 
> > > I'm bringing this up, because the proposed patch doesn't deal with the
> > > above open questions as of yet. With that being said, it's mostly
> > > identical to the proposed hotspot changes in [1].
> 
> For issue 1 and 2 …
> 
> I wonder if we should change the API to throw UnsupportedOperationException 
> for those methods 
> that are not available.  This exception is used quite a lot in the java/nio 
> and java/net packages
> for dealing with functionality not available on a host platform.
> 
> As an alternate suggestion, we already return -2 for "not supported" for most 
> APIs in the hotspot
> implementation.  We could use this for non boolean values in the Metrics API. 
>  For boolean
> values, we could change the API to return “Boolean”.  A null return would 
> signify not
> implemented.

This alternative has been implemented in the latest webrev.
LauncherHelper has been updated to print "N/A" if some property being
printed is not supported. Example output for cgroupsv2:

$ ./bin/java -XshowSettings:system -version
Operating System Metrics:
Provider: cgroupv2
Effective CPU Count: 4
CPU Period: 10us
CPU Quota: -1
CPU Shares: -1
List of Processors: N/A
List of Effective Processors: N/A
List of Memory Nodes: N/A
List of Available Memory Nodes: N/A
CPUSet Memory Pressure Enabled: N/A
Memory Limit: Unlimited
Memory Soft Limit: Unlimited
Memory & Swap Limit: Unlimited
Kernel Memory Limit: N/A
TCP Memory Limit: N/A
Out Of Memory Killer Enabled: N/A

openjdk version "15-internal" 2020-09-15
OpenJDK Runtime Environment (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2)
OpenJDK 64-Bit Server VM (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2, 
mixed mode, sharing)

> > > Bug: https://bugs.openjdk.java.net/browse/JDK-823
> > > webrev: 
> > > http://cr.openjdk.java.net/~sgehwolf/