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

_REALTIME) are supposed to be 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

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, [email protected] wrote: Nashorn engine removal fix (8241749: Remove the Nashorn JavaScript Engine) missed updating few tests, con

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, [email protected] 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(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: https://

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 co

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

ggest. Updated webrev: 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:

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 p

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 sun.hot

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 specif

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 push

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: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

n openjdk is able to update dependencies 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, Dan

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: 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 un

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

something like 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:2

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 Cla

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: https://bugs.openjdk.java.net/browse/JDK-8245600

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 J

Re: RFR: 8245455: Remove alternative StringConcatFactory strategies

80 [1].   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, undocum

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

this webrev. They are covered by the javac webrev (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: "

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 implementa

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

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:[email protected]>> wrote: b

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: 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: http://cr.openjdk.java.net/~mchung/jdk15

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

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/JDK-8242504 webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ This work was contributed by Mark

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

required. Some --test-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://bug

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: JDK-8225056 VM support for sealed classes

(as 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, Davi

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 the

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. Daugh

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: http://cr.ope

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: http://cr.openjdk.java.net/~hsei

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 and

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 was to

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: 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 src/jdk.zipfs/share/classes/jdk/nio/zipf

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: RFR: JDK-8225056 VM support for sealed classes

nks, Harold On 5/28/2020 8:30 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.8

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

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 J

Re: Sometimes constraints are questionable

of additional call sites? 4) We might want to consider refactoring PriorityBlockingQueue and ArrayDeque to use ArraysSupport.newLength, in order to provide a consistent policy for collections. Other growable-array-based collections (Vector, ArrayList, PriorityQueue) do already. s'mar

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: It’

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 -- http://cr.openjdk.j

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 s

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

 {windows,linux,macosx}-x64  - tier1 job (in progress) Thanks, -- Igor On Jun 14, 2020, at 11:23 PM, David Holmes <mailto:[email protected]>> wrote: <...> This doesn't seem to move everything under test/hotspot/jtreg/testlibrary_tests/ e.g. ctw directory. this is

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

ong it it currently works 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&#x

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 deleted

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, t

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: [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 load

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, There

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 cons

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 AM,

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/ Th

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 illu

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 builds.

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, [email protected] wrote: LGTM, thanks for fixing,

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

ately 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 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 exhaustio

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

if those 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

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 [email protected] :) 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 nee

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 interf

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

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 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

bjvm.so+0xd00fc1]  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+0x

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

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(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 we

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 o

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 deter

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

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: 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 the

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, Da

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: 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 f

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

Hi Sundar, On 18/08/2020 12:25 pm, [email protected] 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 copyrigh

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 libjli/java_

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 `@sinc

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` from

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 jt

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 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=822

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 differe

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

On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

On Thu, 10 Sep 2020 13:29:29 GMT, Severin Gehwolf wrote: >> Just noting here that @galderz is a Red Hat employee and should be covered >> by the Red Hat OCA: >> https://www.oracle.com/technical-resources/oracle-contributor-agreement.html#r > > @galderz We'll have to wait until somebody marks you

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

On Fri, 11 Sep 2020 07:03:37 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

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

On Fri, 11 Sep 2020 07:36:57 GMT, Aleksei Voitylov wrote: >> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: >> >>> 280: >>> 281: pthread_attr_init(&thread_attr); >>> 282: pthread_attr_setstacksize(&thread_attr, stack_size); >> >> Just a comment in response to the explanat

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

On Wed, 9 Sep 2020 00:08:35 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Attempting to use the Gi

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape an

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

On 14/09/2020 6:18 pm, Richard Reingruber wrote: On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: Hi, this is the continuation of the review of the implementation for: https://bugs.openjdk.java.net/browse/JDK-8227745 https://bugs.openjdk.java.net/browse/JDK-8233915 It allows for JIT

Re: Request for review of JDK-8251548

Hi Sergey, Since OpenJDK has moved to git/github, this needs to reformulated as a Pull Request (PR). Cheers, David On 17/09/2020 5:19 pm, Сергей Цыпанов wrote: Hello, is it possible to have a code review for the changes proposed in JDK-8251548? Sean Mullan has created an issue and web-revi

Re: Request for review of JDK-8251548

y for the issue." [1] https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 Cheers, David - Regards, Sergey 1. https://github.com/openjdk/jdk/pull/218 17.09.2020, 09:22, "David Holmes" : Hi Sergey, Since OpenJDK has moved to git/github, this needs to reform

Re: Request for review of JDK-8251548

David - Cheers, Sergey 17.09.2020, 14:11, "David Holmes" : On 17/09/2020 7:24 pm, Сергей Цыпанов wrote:  Hi David,  thanks for pointing this out!  I've created a PR there [1], but GitHub for some reason wants me to sign OCA,  which I have already signed in 2017. I've r

Re: Looking for a sponsor for JDK-8138732

Hi Philippe, On 22/09/2020 3:57 pm, Philippe Marschall wrote: Hello I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate PR is here [2]. Sorry I can't volunteer to sponsor this. Changes between the current code and the reviewed code: - I removed the jdk.internal export to

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

On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no wa

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

On Wed, 23 Sep 2020 13:23:43 GMT, Monica Beckwith wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

On Thu, 24 Sep 2020 04:57:39 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequ

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

Hi Chris, Monica, On 25/09/2020 1:47 am, Chris Plummer wrote: As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of other non-SA files that are new and also have the same copyright issue. If a file was created completely from sc

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3]

On Thu, 24 Sep 2020 16:59:03 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on e

  1   2   3   4   5   6   7   8   9   10   >