Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

HI, Mandy   Thanks for the review, I took one day off yesterday so just got a detail look of your reply. On 8/19/20 1:30 PM, Mandy Chung wrote: On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks for review/suggestion. I have updated the webrev at the following link: http://cr.openjdk.jav

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

HI, I hate pinging, but I would really appreciate it if someone finds the time to take a look at my suggestion below from last week. Or is this maybe the wrong mailing list - given that it is in the "sun" root package? Cheers, Christoph = ORIGINAL MAIL = Hi, I just stumbled upon sun

Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

Hi Roger, Thank you for your reply. I wasn't aware of this practice, and will get to work on creating and contributing a test. Regards, - Corey On 8/19/20 11:20 AM, Roger Riggs wrote: Hi Corey, For changes obviously performance motivated, it is conventional to run a JMH perf test to demo

RFR 8251989: Hex encoder and decoder utility

Please review a java.util.Hex API to encode and decode hexadecimal strings to and from byte arrays. Within the JDK and JDK tests there are multiple implementations to encode and decode hexadecimal strings to byte arrays. Hex encoders and decoders support upper or lower case hexadecimal charact

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks for review/suggestion. I have updated the webrev at the following link: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/ This patch leverages the TRACE_RESOLVE output and passes the trace output to VM.  VM then calls Generate

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Naoto, Looks good, thanks for the updates. Roger On 8/19/20 2:26 PM, naoto.s...@oracle.com wrote: Hi Roger, Thank you for your comments. I've addressed your suggestions and created a new webrev below: https://cr.openjdk.java.net/~naoto/8251499/webrev.03/ Naoto On 8/19/20 8:33 AM, Rog

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Roger, Thank you for your comments. I've addressed your suggestions and created a new webrev below: https://cr.openjdk.java.net/~naoto/8251499/webrev.03/ Naoto On 8/19/20 8:33 AM, Roger Riggs wrote: Hi Naoto, CompactNumberFormat.java: 269: The field "placeHolders" should be named consi

Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

Hi Corey, For changes obviously performance motivated, it is conventional to run a JMH perf test to demonstate the improvement and prove it is worthwhile to add code complexity. I don't see any existing Base64 JMH tests but they would be in the repo below or near:     test/micro/org/openjdk/

Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

Michihiro Horie posted up a new iteration of this webrev for me. This time the webrev includes a complete implementation of the intrinsic for Power9 and Power10. You can find it here: http://cr.openjdk.java.net/~mhorie/8248188/webrev.02/ Changes in webrev.02 vs. webrev.01: * The method hea

Re: Possible subtle memory model error in ClassValue

Yes. Core library code close to the JVM in OpenJDK (that in the java.base module, commonly that in java.lang.* close to that in hotspot) often assumes implementation specifics of the JVM. The two are closely coupled. There are other such implementation-specific contracts like @Stable, or “final

Re: RFR: JDK-8251397 NPE on ClassValue.ClassValueMap.cacheArray

Hi Galder, Thanks for doing the fix and the work verifying. I also verified using a fence fixes the jcstress test. Similarly, I found I could only reproduce the issue in HotSpot when running a test more like ClassValue (the double checked locking pattern when publishing to a plan field) with t

Re: Fix for Javadoc errors in java.base

Looks fine Julia On 8/18/20 1:02 PM, Julia Boes wrote: Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 23:55:41.953638446 +0530 +++ new/src/java.base/sha

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Naoto, CompactNumberFormat.java: 269: The field "placeHolders" should be named consistently with the other holders of Patterns.   -> placeHolderPatterns 1632: missing space before ":" 2390:  I'm not sure why the stream processing is preferable to a direct forEach(...). TestCompactPatte

Re: Possible subtle memory model error in ClassValue

On Mon, Aug 10, 2020 at 2:19 PM Doug Lea wrote: > Catching up... > > As implied in other posts, the minimal fix is to add a trailing release > fence (using Unsafe?) to the constructor. FYI I have sent an RFR with the proposed fix ^ https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-Augu

RFR: JDK-8251397 NPE on ClassValue.ClassValueMap.cacheArray

Hi all, I've created patch [1] to fix the ClassValue$ClassValueMap NPE bug in [2]. The bug has been discussed by other members in the list in thread [3]. The patch follows the simple fix suggested by Doug and others in that exchange, e.g. [4]. That is, it adds a release fence to ClassValue$Class