Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote: >> This should be broken up to deal with the files in different functional >> areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas >> need to be reviewed by

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote: >> @kevinrushforth thanks. Done. >> >> Similar issues: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 >>

Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port

On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package

On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I > believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since`

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package

Hi Philippe, On 8/09/2020 3:08 am, Philippe Marschall wrote: Hello, newbie here Welcome aboard! I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. - I tried to update the copyright year to 2020 in every file. - I decided to change

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

Hi Aleksei, Overall this all seems okay. A few minor comments below. On 1/09/2020 9:41 pm, Aleksei Voitylov wrote: Hi, JEP 386 is now Candidate [1] and as we resolved all outstanding issues within the Portola project I'd like to ask for comments from HotSpot, Core Libs (changes in

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

Hi Sundar, On 18/08/2020 12:25 pm, sundararajan.athijegannat...@oracle.com wrote: Not a full review of fresh changes. But couple of comments: * src/hotspot/share/memory/lambdaFormInvokers.cpp and src/hotspot/share/memory/lambdaFormInvokers.hpp miss "Classpath exception" clause in the

Re: Possible subtle memory model error in ClassValue

For DCL to be correct Class.classValueMap should be declared volatile. Final field guarantees are there to support unsafe publication in special cases. In this case we should be using safe publication. Cheers, David On 8/08/2020 9:22 am, Paul Sandoz wrote: Here’s some pertinent information

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

On 6/08/2020 7:37 am, Joe Darcy wrote: Hello, Addressing some feedback from off-list discussions with Mandy, I propose changing the API notes to:     @apiNote While to date a wildcard may have at most one upper[lower] bound, callers of this method should be written to accommodate multiple

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

one upper/lower bound. "to date" is just another form of "in the current version". Sorry I find it hard to suggest suitable text when I don't think it necessary to say anything. Best to let others endorse this one. Cheers, David - -Joe On 8/2/2020 7:22 PM, David H

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

Hi Joe, I was under the impression that using phrases like "the current version of" were superfluous as all such documentation implicitly refers to the current version, unless explicitly stated otherwise. Personally I'm not sure this clarification really makes a difference to anything as

Re: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics

Update looks good. Thanks, David On 29/07/2020 12:01 am, Severin Gehwolf wrote: Hi David, Thanks for the review. On Tue, 2020-07-28 at 23:49 +1000, David Holmes wrote: Hi Severin, On 28/07/2020 11:23 pm, Severin Gehwolf wrote: Hi David, On Tue, 2020-07-28 at 21:17 +1000, David Holmes

Re: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics

Hi Severin, On 28/07/2020 11:23 pm, Severin Gehwolf wrote: Hi David, On Tue, 2020-07-28 at 21:17 +1000, David Holmes wrote: Hi Severin, On 28/07/2020 6:27 pm, Severin Gehwolf wrote: Hi, Please review this patch which makes the Java container metrics adhere to -XX:+/-UseContainerSupport so

Re: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics

Hi Severin, On 28/07/2020 6:27 pm, Severin Gehwolf wrote: Hi, Please review this patch which makes the Java container metrics adhere to -XX:+/-UseContainerSupport so they can be disabled if heuristics turn out to be wrong. The approach taken is to use JNI and call into the JVM in order to

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

Hi Kim, On 22/07/2020 6:04 pm, Kim Barrett wrote: On Apr 8, 2020, at 5:27 AM, David Holmes wrote: Hi Kim, Apparently I lost track of these comments and forgot to respond. Thanks for the follow up - I figured it was all "on hold". Cheers, David I still won't be sending out a

Re: RFR(s): Support graceful application termination on Windows shutdown/logoff

Hi Nikola, I'm redirecting this to the core-libs team initially because this is an issue that has been raised and discussed considerably in the past (possibly with some misunderstanding relating to the WM_ENDSESSION event). The core-libs team need to confirm the intended semantics here and

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

Still good. Thanks, David On 24/07/2020 12:11 am, Roger Riggs wrote: Webrev updated with Martin's suggestion: http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/ Thanks, Roger On 7/22/20 8:35 PM, Martin Buchholz wrote: Roger: You're absolutely right!  I should have looked.

Re: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h in native tests

Thanks Mandy! David On 23/07/2020 2:22 pm, Mandy Chung wrote: Hi David, Looks good. Mandy On 7/22/20 4:00 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8249940 webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/ A number of native tests in hotspot and jdk

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

c1]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xb1 V  [libjvm.so+0xe7ed63]  thread_entry(JavaThread*, Thread*)+0x123 V  [libjvm.so+0x16d3f9c]  JavaThread::thread_main_inner()+0x21c V  [libjvm.so+0x16d9d20]  Thread::call_run()+0x100 V  [libjvm.so+0x13ddbe6]  thread_

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

Hi Roger, On 23/07/2020 12:51 am, Roger Riggs wrote: Please review a change to the Process reaper thread initialization to preemptively make sure classes ThreadLocalRandom and ConcurrentHashMap are initialized. I don't see ThreadLocalRandom appearing in any of the stack traces. ?? David

Re: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h in native tests

Thanks Igor! David On 23/07/2020 9:09 am, Igor Ignatyev wrote: Hi David, looks good to me. -- Igor On Jul 22, 2020, at 4:00 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8249940 webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/ A number of native tests

RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h in native tests

Bug: https://bugs.openjdk.java.net/browse/JDK-8249940 webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/ A number of native tests in hotspot and jdk include the jni_util.h header file which is part of the sources for libjava and not part of the testing framework, nor an exported

Re: Build error with GCC 10 in NetworkInterface.c and k_standard.c

If you are going to change makefiles you need to get review on build-...@openjdk.java.net :) David On 17/07/2020 11:48 pm, Yasumasa Suenaga wrote: Hi Koichi, On 2020/07/17 20:26, Koichi Sakata wrote: Hi Daniel,  > The changes to NetworkInterface.c look good to me. Thank you.  > You'll

Re: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)

se strings are allocated on the side per se and are subject to the platforms VM whims. On Jul 14, 2020, at 8:36 PM, David Holmes wrote: On 15/07/2020 5:35 am, Roger Riggs wrote: Looks good. Though it does seem like the VM should have been able to reclaim enough memory between tests to not need to throw O

Re: Fwd: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)

On 15/07/2020 5:35 am, Roger Riggs wrote: Looks good. Though it does seem like the VM should have been able to reclaim enough memory between tests to not need to throw OOME. I'd have to agree with that - something seems strange here. The first OOME in OOM1 is not actually Java heap

Re: RFR 15: 8217475: Unexpected StackOverflowError in "process reaper" thread

failures are still happening after the push. https://bugs.openjdk.java.net/browse/JDK-8249217 David - Thanks, Roger On 7/9/20 4:54 AM, David Holmes wrote: Hi Roger, Looks good to me. Thanks, David On 9/07/2020 6:51 am, Roger Riggs wrote: Please review a change to increase the size

Re: RFR(T): 8249097: test/lib/jdk/test/lib/util/JarBuilder.java has a bad copyright

On 9/07/2020 7:24 am, Daniel D. Daugherty wrote: Thanks for the fast review. I was surprised that jcheck -r tip didn't flag that, but... :-) jcheck doesn't check copyright lines or file headers. Cheers, David Dan On 7/8/20 5:23 PM, igor.ignat...@oracle.com wrote: LGTM, thanks for

Re: RFR 15: 8217475: Unexpected StackOverflowError in "process reaper" thread

Hi Roger, Looks good to me. Thanks, David On 9/07/2020 6:51 am, Roger Riggs wrote: Please reveiw a change to increase the size of the Process Reaper stack for debug builds. This intermittent issue can be traced to the stack shadow page size being larger in debug builds than in release

Re: Scalar replacement issue in JDK 14.0.1

Hi Sergie, This seems like a question for hotspot-compiler-dev rather than core-libs-dev. Thanks, David On 26/06/2020 10:06 pm, Сергей Цыпанов wrote: Hello, while looking into an issue I've found out that scalar replacement is not working in trivial case on JDK 14.0.1. This benchmark

Re: RFR: JDK-8240148: Uncaught exceptions from ScheduledThreadPoolExecutor.execute aren't reported

Hi Jaikiran, On 24/06/2020 11:44 pm, Jaikiran Pai wrote: Could I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8240148? I missed the filing of this bug. :( The patch is available as a webrev at https://cr.openjdk.java.net/~jpai/webrev/8240148/1/

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

On 25/06/2020 5:21 am, Mandy Chung wrote: Hi Roger, David, Thanks for the help in improving this.  As a record, this webrev shows the version as David suggests: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247785/webrev.00/ Looks good to me :) Thanks, David Mandy On 6/24/20 9:33

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

Hi Chris, On 24/06/2020 2:30 am, Chris Hegarty wrote: On 23 Jun 2020, at 14:49, Peter Levart wrote: ... Ok, I'm going to push this to jdk15. Thank you Peter. This is a really nice change. As a follow on, and not for JDK 15, I observe that Class::isRecord0 / JVM_IsRecord shows up as

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

On 24/06/2020 1:17 pm, Mandy Chung wrote: On 6/23/20 7:48 PM, David Holmes wrote: Hi Mandy, The trouble with small clarifications is that they tend to draw attention to larger issues :) On 24/06/2020 7:42 am, Mandy Chung wrote: On 6/23/20 12:01 PM, Roger Riggs wrote: Hi Mandy

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

Hi Mandy, The trouble with small clarifications is that they tend to draw attention to larger issues :) On 24/06/2020 7:42 am, Mandy Chung wrote: On 6/23/20 12:01 PM, Roger Riggs wrote: Hi Mandy, There may be a missing "to" in: + * Platform classes are visible the platform class

Re: [PATCH] remove redundant initialization of volatile fields with default values

On 19/06/2020 11:25 pm, David Holmes wrote: Hi Remi, On 19/06/2020 6:03 pm, Remi Forax wrote: Hi Sergei, the problem is that you are changing the semantics if there are several fields. By example with the code below, you have the guarantee that the code will print 4 (if it prints something

Re: [PATCH] remove redundant initialization of volatile fields with default values

Hi Remi, On 19/06/2020 6:03 pm, Remi Forax wrote: Hi Sergei, the problem is that you are changing the semantics if there are several fields. By example with the code below, you have the guarantee that the code will print 4 (if it prints something), if you remove the assignment field = false,

Re: RFR: [15,docs] JDK-8247899,HTML errors and warnings in threadPrimitiveDeprecation.html

Looks good and trivial! Thanks, David On 19/06/2020 10:18 am, Jonathan Gibbons wrote: Please review this trivial fix to some minor issues reported by doclint. In the first change, the ``  contained a hangover of some HTML 4 attributes which are not supported in HTML5. They are simply

Re: RFR(S) : 8211977 : move testlibrary tests into one place

s reliably. Thanks, David Thanks, -- Igor On Jun 16, 2020, at 12:14 AM, David Holmes wrote: Hi Igor, On 16/06/2020 10:39 am, Igor Ignatyev wrote: @David, Erik, Magnus, please find the answers to your comments at the bottom of this email. @all, David's and Erik's comments made me realize that

Re: RFR(S) : 8211977 : move testlibrary tests into one place

-- Igor On Jun 14, 2020, at 11:23 PM, David Holmes <mailto:david.hol...@oracle.com>> wrote: <...> This doesn't seem to move everything under test/hotspot/jtreg/testlibrary_tests/ e.g. ctw directory. this is intentionally, ctw test-library is hotspot specific, hence its tests

Re: (15) RFR: JDK-8247444: Trust final fields in records

Hi Mandy, Christoph, The code changes here all look okay to me. The idea of introducing the notion of "trusted final fields" seems quite reasonable. I made one editorial comment on the CSR request. I'm unclear if the new TEST.properties file needs a copyright notice and header. We have 706

Re: RFR(S) : 8211977 : move testlibrary tests into one place

Hi Igor, I found this all a bit hard to follow. It would have been clearer if broken up into distinct pieces. On 13/06/2020 2:10 pm, Igor Ignatyev wrote: testing revealed that LingeredAppTest.java required some love, incremental webrev w/ the fixes for LingeredAppTest --

Re: ThreadGroup.enumerate/activeCount - any good reason not to deprecate?

Hi Alan, I've always thought ThreadGroups were a good idea that were never communicated very well. The notion of a ThreadGroup as a security context potentially had some value that was never truly realized. On 4/06/2020 4:40 am, Alan Bateman wrote: On 03/06/2020 18:47, Paul Sandoz wrote:

Re: Sometimes constraints are questionable

to use ArraysSupport.newLength, in order to provide a consistent policy for collections. Other growable-array-based collections (Vector, ArrayList, PriorityQueue) do already. s'marks On 6/1/20 4:47 AM, Jim Laskey wrote: Thanks David will run with that, On May 31, 2020, at 8:34 PM, David

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi Mandy, On 3/06/2020 4:38 am, Mandy Chung wrote: Hi Calvin, To recap an offline discussion, I think we should use JDK bootcycle build to test this feature.  For example generating a boot JDK with archived lambda proxy classes for java.base and javac to build itself and also use it to run

Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

Hi Daniel, Sorry the weekend got in the way :) On 29/05/2020 7:01 pm, Daniel Fuchs wrote: Hi David, Thanks for the feedback! On 29/05/2020 00:36, David Holmes wrote: This seems to be assuming that the GC will clear all SoftReferences when it needs to clear any SoftReference. I don't think

Re: RFR: JDK-8225056 VM support for sealed classes

PM, David Holmes wrote: Hi Harold, Sorry Mandy's comment raised a couple of issues ... On 29/05/2020 7:12 am, Mandy Chung wrote: Hi Harold, On 5/27/20 1:35 PM, Harold Seigel wrote: Incremental webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ full webrev: http

Re: Sometimes constraints are questionable

On 1/06/2020 9:52 am, Martin Buchholz wrote: On Sun, May 31, 2020 at 4:35 PM David Holmes wrote: Not sure how we could have minCapacity < 0 at this point. It should have been checked before the call to grow, and grow will not make it negative. At least some of the grow methods were desig

Re: Sometimes constraints are questionable

On 31/05/2020 12:29 am, Jim Laskey wrote: I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . I'm wondering why hugeCapacity in

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 30/05/2020 6:03 am, Mandy Chung wrote: On 5/28/20 9:18 PM, David Holmes wrote: On 29/05/2020 1:52 pm, Mandy Chung wrote: On 5/28/20 5:44 PM, David Holmes wrote: This is to validate the given version.  The runtime will check if preview feature is enabled when such class file is loaded

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 29/05/2020 1:52 pm, Mandy Chung wrote: On 5/28/20 5:44 PM, David Holmes wrote: This is to validate the given version.  The runtime will check if preview feature is enabled when such class file is loaded. I will make a comment to make it clear. Okay but I thought the intent here

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

Hi Mandy, On 29/05/2020 3:28 am, Mandy Chung wrote: On 5/28/20 12:44 AM, David Holmes wrote: Hi Mandy, On 28/05/2020 2:13 pm, Mandy Chung wrote: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ I modify this patch to check the class file version

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Harold, Sorry Mandy's comment raised a couple of issues ... On 29/05/2020 7:12 am, Mandy Chung wrote: Hi Harold, On 5/27/20 1:35 PM, Harold Seigel wrote: Incremental webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ full webrev:

Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

Hi Daniel, This caught my eye ... On 28/05/2020 6:50 pm, Daniel Fuchs wrote: Hi, Please find an almost trivial fix for: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" https://bugs.openjdk.java.net/browse/JDK-8245867 webrev:

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

Thanks Dan! David On 28/05/2020 12:52 pm, Daniel D. Daugherty wrote: I'll wait for your thumbs up on the explanation. I'm good with the explanation. Thanks! Dan On 5/27/20 10:08 PM, David Holmes wrote: Hi Dan, Thanks for taking a look. On 28/05/2020 1:09 am, Daniel D. Daugherty wrote

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

Hi Mandy, On 28/05/2020 2:13 pm, Mandy Chung wrote: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ I modify this patch to check the class file version and throws CFE if unsupported before creating ClassReader.  This also fixes JDK-8245061 that it reads

Re: RFR: JDK-8225056 VM support for sealed classes

specified in the JVM Spec) instead of VerifyError. * Added a check that a non-public subclass must be in the same package as its sealed super.  And added appropriate testing. * Method Class.permittedSubtypes() was changed. See also inline comments. On 5/24/2020 10:28 PM, David Hol

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

Hi Dan, Thanks for taking a look. On 28/05/2020 1:09 am, Daniel D. Daugherty wrote: On 5/26/20 12:59 AM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8242504 webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ src/hotspot/os/posix/os_posix.hpp     No comments

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

st-repeat might be in order to verify things are stable but I don't expect any issue there :-) LGTM. best regards, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8068730 On 26/05/2020 05:59, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8068730 On 26/05/2020 05:59, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8242504 webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ This work was contributed by Mark Kralj-Taylor: https

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

Hi Mandy, On 27/05/2020 7:46 am, Mandy Chung wrote: Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes are of unsupported class file version.  The implementation should catch and throw UnsupportedClassVersionError instead. webrev:

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

Thanks Roger! David On 27/05/2020 12:28 am, Roger Riggs wrote: Looks good. Thanks to Mark and you for the improvement and testing. On 5/26/20 12:59 AM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8242504 webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

os::javaTimeNanos. IIRC I introduced the local to allow adding a printf before the return when debugging the conversion :) I should have removed it again. Thanks, David Vyom On Tue, May 26, 2020 at 10:29 AM David Holmes <mailto:david.hol...@oracle.com>> wrote: b

Re: RFR(S) 8242504: Enhance the system clock to nanosecond precision

On 26/05/2020 6:14 pm, Stephen Colebourne wrote: AFAICT a nanosecond clock is fine from a java.time.* API perspective. Thanks Stephen. Is this a review or just a nod of approval? :) Cheers, David - Stephen On Tue, 26 May 2020 at 06:01, David Holmes wrote: bug: https

RFR(S) 8242504: Enhance the system clock to nanosecond precision

bug: https://bugs.openjdk.java.net/browse/JDK-8242504 webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ This work was contributed by Mark Kralj-Taylor: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html On the hotspot side we change the Linux

Re: RFR: JDK-8225056 VM support for sealed classes

brev (JDK-8244556). 8. The CSR's for JVMTI, JDWP, and JDI are in progress. Please also see comments inline. On 5/19/2020 1:26 AM, David Holmes wrote: Hi Harold, Adding serviceability-dev for the serviceability related changes. Nit: "VM support for sealed classes" This RFR covers th

Re: RFR: 8245455: Remove alternative StringConcatFactory strategies

].   Maybe other CSR? Mandy [1] https://bugs.openjdk.java.net/browse/CCC-8085796 On 5/23/20 6:18 AM, David Holmes wrote: Hi Claes, You are removing a property so this needs a CSR request. Thanks, David On 22/05/2020 7:52 pm, Claes Redestad wrote: Hi, this patch removes the alternative, undocumented

Re: RFR: 8245455: Remove alternative StringConcatFactory strategies

Hi Claes, You are removing a property so this needs a CSR request. Thanks, David On 22/05/2020 7:52 pm, Claes Redestad wrote: Hi, this patch removes the alternative, undocumented strategies from StringConcatFactory. The default strategy has been optimized and stabilized since inception in

Re: RFR(S): 8245600: Clean up libjli

Hi Mikael, Cleanup looks good to me. Bikeshed: TimeGetNowMicros -> GetTimeMicros or CurrentTimeMicros ? Thanks, David On 22/05/2020 1:28 pm, Mikael Vidstedt wrote: Please review this change which cleans up the libjli related files a bit: JBS:

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Vicente, On 21/05/2020 1:40 am, Vicente Romero wrote: Hi David, src/java.base/share/classes/java/lang/Class.java There needs to be a CSR request for these changes. yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 +  * Returns an array containing {@code

Re: RFR: JDK-8225056 VM support for sealed classes

this webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/redef-spec-dedup.1/ If the direction looks okay then I could file RFE+CSR (and post an RFR). I like the idea of keeping one list referred to by the other specs! Thanks, David - Thanks, Serguei On 5/18/20 22:26, David Holmes

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Harold, Adding serviceability-dev for the serviceability related changes. Nit: "VM support for sealed classes" This RFR covers the VM, core-libs, serviceability and even some langtools tests. AFAICS only the javac changes are not included here so when and where will they be reviewed and

Re: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518

Ship it! (though should have gone to core-libs-dev cc'd) Thanks, David On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote: Hi. Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

ies to newer OS versions. Especially if openjdk can be built on its minimum required per-platform OS version in a (Docker) container. Mark On Tue, 14 Apr 2020 at 23:34, David Holmes wrote: Hi Mark, On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote: David, Daniel, What is the oldest (lowest) vers

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

On 7/05/2020 12:04 pm, Daniel D. Daugherty wrote: On 5/6/20 9:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ src/java.base/share/native/libjimage/imageDecompressor.cpp  

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Hi Yumin, On 7/05/2020 11:01 am, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750

Re: RFR(S) 8241071 Generation of classes.jsa is not deterministic

Hi Ioi, On 5/05/2020 3:43 am, Ioi Lam wrote: On 4/27/20 7:05 PM, David Holmes wrote: On 28/04/2020 10:01 am, David Holmes wrote: On 28/04/2020 9:37 am, Ioi Lam wrote: Hi David & Jiangli, Thanks for your comments. I thought about using a system property, but the user can also spe

Re: RFR(T) : 8244052 : remove copying of s.h.WB$WhiteBoxPermission in test/jdk

Looks good! Thanks, David On 29/04/2020 1:20 pm, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ 34 lines changed: 0 ins; 11 del; 23 mod; Hi all, could you please review this trivial patch? from JBS: JDK-8199290 made it unnecessary to explicitly pass

Re: RFR(S) 8241071 Generation of classes.jsa is not deterministic

On 28/04/2020 10:01 am, David Holmes wrote: On 28/04/2020 9:37 am, Ioi Lam wrote: Hi David & Jiangli, Thanks for your comments. I thought about using a system property, but the user can also specify it like java -Djdk.xshare.dump.salt=0 MyProgram There's a way to pass proper

Re: RFR(S) 8241071 Generation of classes.jsa is not deterministic

http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v03/ http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v03.delta/ More comments below On 4/26/20 11:20 PM, David Holmes wrote: Hi Ioi, On 27/04/2020 3:22 pm, Ioi Lam wrote: https://bugs.openjdk.java

Re: RFR(S) 8241071 Generation of classes.jsa is not deterministic

Hi Ioi, On 27/04/2020 3:22 pm, Ioi Lam wrote: https://bugs.openjdk.java.net/browse/JDK-8241071 http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/ The goal is to for "java -Xshare:dump" to produce deterministic contents in the CDS archive that depend only on the

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

Hi Bin, On 24/04/2020 7:28 pm, buddyliao(廖彬) wrote: Dear all, As Lin mentioned, I found the copyright info is not updated, so I prepared a patch to fix this. Lin helps me to build an issue in the jdk bug system. Would you help me to review this patch? Thank you very much. Patch link:

Re: RFR 8242931: Few more tests that use nashorn have been missed

looked reasonable. You have my review. best regards, -- daniel On 16/04/2020 17:26, sundararajan.athijegannat...@oracle.com wrote: Please review updated webrev: http://cr.openjdk.java.net/~sundar/8242931/webrev.01/ Thanks, -Sundar On 16/04/20 6:49 pm, David Holmes wrote: +1 Please problem

Re: RFR 8242931: Few more tests that use nashorn have been missed

+1 Please problem list the tests under the associated bug ids. Thanks, David On 16/04/2020 11:10 pm, Alan Bateman wrote: On 16/04/2020 13:59, sundararajan.athijegannat...@oracle.com wrote: Nashorn engine removal fix (8241749: Remove the Nashorn JavaScript Engine) missed updating few tests,

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

the same clocksource. i.e. that given by: cat /sys/devices/system/clocksource/clocksource0/current_clocksource Mark On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs wrote: Hi, On 11/04/2020 00:53, David Holmes wrote: Update: It's a holiday weekend so I can't dig into this right now but we tried us

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

Update: On 11/04/2020 9:45 am, David Holmes wrote: Hi Mark, Thanks for the very detailed proposal and write up! It's a holiday weekend so I can't dig into this right now but we tried using a high-precision clock source for systemUTC() in the past but it didn't work because systemUTC

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

Hi Mark, Thanks for the very detailed proposal and write up! It's a holiday weekend so I can't dig into this right now but we tried using a high-precision clock source for systemUTC() in the past but it didn't work because systemUTC() and currentTimeMillis() have to use the same time base,

Re: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file

rev. Regards, Evgeny. On 2020-04-07 14:50, David Holmes wrote: Hi Evgeny, On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: Hi David, I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed. Well, it's mostly used for

Re: Need sponsor to fix Javadoc warnings

-prone that can be, I still wouldn't do it in this changeset. -Pavel On 8 Apr 2020, at 13:56, David Holmes wrote: Hi Pavel, Not a review ... On 8/04/2020 9:50 pm, Pavel Rappo wrote: Vipin, here you go: https://bugs.openjdk.java.net/browse/JDK-8242366 http://cr.openjdk.java.net

Re: Need sponsor to fix Javadoc warnings

on cr.openjdk.java.net Please suggest if there is any way I can create my user id to upload this patch. This is ~300 line patch file. Regards, Vipin On Apr 6, 2020, at 3:25 AM, David Holmes wrote: Hi Vipin, On 6/04/2020 6:42 am, Vipin Sharma wrote: Hi, I have fixed a few warnings where the method

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

Hi Kim, On 8/04/2020 10:25 am, Kim Barrett wrote: [Note review on both core-libs and hotspot-gc-dev lists; try not to lose either when replying.] Please review a new function: java.lang.ref.Reference.refersTo. This function is needed to test the referent of a Reference object without

Re: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file

eed to see any update if you chose to make it. Thanks, David - Best Regards, Evgeny. On 2020-04-02 02:07, David Holmes wrote: Thanks for sharing this Igor! I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

819 #include Thanks, David - The current build only use that for static build launcher, not custom launcher use libjli. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.2/webrev/ On Apr 5, 2020, at 9:21 PM, David Holmes wrote: On 6/04/2020 12:37 pm, David Holmes wrote

Re: Need sponsor to fix Javadoc warnings

will offer to do that soon. Thanks, David This is ~300 line patch file. Regards, Vipin On Apr 6, 2020, at 3:25 AM, David Holmes wrote: Hi Vipin, On 6/04/2020 6:42 am, Vipin Sharma wrote: Hi, I have fixed a few warnings where the method parameter name is different in code and Javadoc, need

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

On 6/04/2020 12:37 pm, David Holmes wrote: On 6/04/2020 12:20 pm, Henry Jen wrote: On Apr 5, 2020, at 7:15 PM, David Holmes wrote: On 6/04/2020 11:50 am, David Holmes wrote: There is something not right here ... On 4/04/2020 3:13 pm, Henry Jen wrote: Internal test shows that inline

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

On 6/04/2020 12:20 pm, Henry Jen wrote: On Apr 5, 2020, at 7:15 PM, David Holmes wrote: On 6/04/2020 11:50 am, David Holmes wrote: There is something not right here ... On 4/04/2020 3:13 pm, Henry Jen wrote: Internal test shows that inline implementation is not working for some Solaris

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

On 6/04/2020 11:50 am, David Holmes wrote: There is something not right here ... On 4/04/2020 3:13 pm, Henry Jen wrote: Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

There is something not right here ... On 4/04/2020 3:13 pm, Henry Jen wrote: Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) [2020-04-03T15:59:26,981Z] Creating

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

ot; wrote: > On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote: > > > On 05/04/2020 14:17, David Holmes wrote: >> On 4/04/2020 3:13 pm, Henry Jen wrote: >>> Internal test shows that inline implementation is not working

Re: Need sponsor to fix Javadoc warnings

Hi Vipin, On 6/04/2020 6:42 am, Vipin Sharma wrote: Hi, I have fixed a few warnings where the method parameter name is different in code and Javadoc, need a sponsor for this patch. Webrev is available at https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e webrevs needs to be

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

On 4/04/2020 3:13 pm, Henry Jen wrote: Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) The problem is in defining that function as inline rather than the

<    1   2   3   4   5   6   7   8   9   10   >