Re: RFR 8203279 : Faster calculation of power of two

On 17/05/2018 12:55 PM, Martin Buchholz wrote: Hello Ivan, I've wondered about this myself. Probably the performance is architecture dependent. Probably a new method should be added to Integer and Long with @HotspotIntrinsicCandidate. That gives David another chance to practice his blind

Re: RFR 8203279 : Faster calculation of power of two

On 17/05/2018 12:30 PM, Ivan Gerasimov wrote: Hi David! On 5/16/18 6:12 PM, David Holmes wrote: Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that numberOfLeadingZeroes is intrinsified! Yes, good point. Please find the benchmark

Re: RFR 8203279 : Faster calculation of power of two

Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that numberOfLeadingZeroes is intrinsified! Cheers, David On 17/05/2018 10:32 AM, Ivan Gerasimov wrote: Hello! In a few places we have code that rounds an integer up to the nearest power of two.

Re: RFR: jsr166 jdk integration 2018-05

On 17/05/2018 4:25 AM, Stuart Marks wrote: On 5/15/18 7:37 PM, David Holmes wrote: I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result

Re: Bug Request: Please remove out-of-date files from bug

Done. Though you sent this to the wrong mailing list for a hotspot bug. David On 17/05/2018 1:36 AM, Adam Farley8 wrote: Hi All, In bug JDK-8190187, hotspot_hg_diff and jdk_hg_diff are out-of-date. Please can someone delete these files? Best Regards Adam Farley OpenJDK Team Runtimes IBM

Re: RFR: jsr166 jdk integration 2018-05

I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result is the programmer won't know what to expect when or why. The original intent of CME, from

Re: RFR: 8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so)

+1 on both comments. In addition I'd prefer + u4 useed = (u4)seed; for clarity, rather than just 's'. Thanks, David On 16/05/2018 2:16 AM, Aleksey Shipilev wrote: On 05/15/2018 06:11 PM, Severin Gehwolf wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8203223 webrev:

[core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

This review is being spread across four groups: langtools, core-libs, hotspot and serviceability. This is the specific review thread for core-libs - webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v1/ See below for full details - including annotated full webrev

Re: RFR: jsr166 jdk integration 2018-05

On 15/05/2018 7:56 AM, Paul Sandoz wrote: On May 14, 2018, at 2:04 PM, Martin Buchholz wrote: On Mon, May 14, 2018 at 1:45 PM, Paul Sandoz > wrote: On May 14, 2018, at 12:43 PM, Martin Buchholz

Re: RFR (S): 8202686: Missing test case for 8200167 - final Object methods

Thanks Vladimir! Sorry I literally just pushed this before I saw your email. David On 8/05/2018 7:31 AM, Vladimir Ivanov wrote: Looks good! Best regards, Vladimir Ivanov On 5/6/18 15:11, David Holmes wrote: webrev: http://cr.openjdk.java.net/~dholmes/8202686/webrev/ bug: https

Re: RFR(M): 8202745: Remove hyphens from "out-of-bounds".

Hi Goetz, The grammar can be a bit subtle here. IIUC we would say: "Index %d out of bounds for length %d" but if we turn it around we'd say: "out-of-bounds index %d for length %d" Anyway changes seem fine to me. Couple of comments below. On 8/05/2018 7:26 AM, Lindenmaier, Goetz wrote: Hi,

Re: RFR (S): 8202686: Missing test case for 8200167 - final Object methods

Thanks Paul! David On 8/05/2018 3:01 AM, Paul Sandoz wrote: I am not too familiar with the overall test but i could follow the logic for the additions, looks good to me. Paul. On May 6, 2018, at 3:11 PM, David Holmes <david.hol...@oracle.com> wrote: webrev: http://cr.openjdk.ja

RFR (S): 8202686: Missing test case for 8200167 - final Object methods

webrev: http://cr.openjdk.java.net/~dholmes/8202686/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8202686 JDK-8200167 added additional checks to ensure receiver typechecks were in place where needed for invokespecial invocations. There was one variation missing in the test: invoking a

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

om] Sent: Dienstag, 24. April 2018 18:17 To: Lindenmaier, Goetz <goetz.lindenma...@sap.com> Cc: David Holmes <david.hol...@oracle.com>; hotspot-runtime- d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; aarch64- port-...@openjdk.java.net; aarch32-port-...@openjdk.java.net;

Re: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue

Hi Claes, On 30/04/2018 10:49 PM, Claes Redestad wrote: Hi, please review this patch to enable caching of getCanonicalName and getSimpleName, repeated calls of which has been reported to be a performance bottleneck. The caching improves performance of these methods by up to 20x. Rather

Re: jdk-submit is offline until Monday

I should have added that the CI testing system is also offline, so any pushes won't hit our internal testing until sometime Monday. David On 28/04/2018 9:19 AM, David Holmes wrote: Just a heads up that due to scheduled maintenance the systems used by jdk-submit will be offline until Monday

jdk-submit is offline until Monday

Just a heads up that due to scheduled maintenance the systems used by jdk-submit will be offline until Monday morning Pacific Time US. David

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

Hi Rafael, On 27/04/2018 6:12 PM, Rafael Winterhalter wrote: Hello, I was wondering if the change in ParameterizedType::toString was intended. https://bugs.openjdk.java.net/browse/JDK-8054213 Cheers, David - I just found my to break after an update due to a test relying on a certain

Re: (M) RFR: 8200167: Validate more special case invocations

Thanks Karen! Once my re-testing has completed I'll look at pushing this. David On 27/04/2018 7:21 AM, Karen Kinnear wrote: Looks good! Thank you so much David and Vladimir for all the work to cover the corner cases. thanks, Karen On Apr 26, 2018, at 12:12 AM, David Holmes <david.

Re: (M) RFR: 8200167: Validate more special case invocations

od. Thanks again! David Best regards, Vladimir Ivanov On 4/25/18 21:12, David Holmes wrote: Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/ Karen formulated an additional test scenario invoking Object methods through an interface reference, which when turned into a

Re: (M) RFR: 8200167: Validate more special case invocations

generates an invokevirtual) - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case. Thanks, David On 17/04/2018 6:48 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ Credit to John Rose

Re: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc

Hi Joe, On 25/04/2018 10:30 AM, joe darcy wrote: Hello, Please review the patch below to update the specification of Long.valueOf(long) to require caching on [-128, 127]. The JDK implementation of this functionality has always cached in that region, even though it is not required. Seems

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

it should not impose any cost on the case without exception. Best regards, Goetz. Thanks, David Thanks, Goetz. -Original Message- From: David Holmes [mailto:david.hol...@oracle.com] Sent: Freitag, 20. April 2018 09:25 To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

a little bit clearer. Thanks, David Thanks, Goetz. -Original Message- From: David Holmes [mailto:david.hol...@oracle.com] Sent: Freitag, 20. April 2018 09:25 To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; hotspot-runtime- d...@openjdk.java.net; hotspot-co

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

le trying to copy to index 7 of a double array with length 5"); Maybe it should say: Arraycopy source index -1 out-of-bounds for double array of length 10. Arraycopy target index 10 out-of-bounds for object array of length 10. Negative range -19 when copying from an object array of len

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

by:  Objects.checkIndex(index, length). Which roughly reads as:    Index %d out-of-bounds for length %d Regards, Roger On 4/18/18 4:54 AM, David Holmes wrote: Adding core-libs-dev as you're changing java.lang.ArrayIndexOutOfBoundsException. I appreciate the intent here but I find the messages excessively

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

Adding core-libs-dev as you're changing java.lang.ArrayIndexOutOfBoundsException. I appreciate the intent here but I find the messages excessively verbose. The basic error is: index N is outside range [0, length-1] David On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: Hi, I would like

Re: JDK 11 RFR of JDK-8201766: Mark TimSortStackSize2.java as intermittently failing

Looks fine to me Joe! Thanks, David On 18/04/2018 1:59 PM, joe darcy wrote: Hello, Please review the patch below to address     JDK-8201766: Mark TimSortStackSize2.java as intermittently failing which marks the test as failing intermittently and demotes it to tier 2 from tier 1. Thanks,

(M) RFR: 8200167: Validate more special case invocations

Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to Tobias Hartmann for the C1 fix. Their help was very much appreciated (and needed!). tl;dr version:

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

On 16/04/2018 11:22 PM, Mario Torre wrote: 2018-04-12 10:12 GMT+02:00 Raffaello Giulietti : I asked Oracle about how the copyright notice should be adapted to meet the OCA requirements but, as of today, I got no answer. All the headers need to have a valid

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

Hi Peter, On 9/04/2018 5:50 PM, Peter Levart wrote: On 04/09/18 08:25, David Holmes wrote: On 7/04/2018 3:11 AM, Tony Printezis wrote: — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote: On Fri

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

earing Could you clarify what you mean by ThreadLocal clearing? I mean calling ThreadLocal#remove(). I see. So, anyone who subclasses ThreadLocal can override remove(). And if remove() is called by Thread::exit, it can be used as an exit hook. (David Holmes, if this is what you meant in your

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

Hi Tony, On 6/04/2018 7:45 AM, Tony Printezis wrote: Hi all, We recently hit another interesting issue with the NIO thread-local DirectByteBuffer cache. One of our services seems to create and drop If it's in a ThreadLocal then aren't you just asking for thread-locals to be cleared at

Re: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory

On 4/04/2018 1:06 PM, Ivan Gerasimov wrote: Hi David! On 4/3/18 6:41 PM, David Holmes wrote: Hi Ivan, On 4/04/2018 10:01 AM, Ivan Gerasimov wrote: Hi David! On 4/3/18 4:49 PM, David Holmes wrote: Hi Ivan, On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: Hello! Yet another occurrence

Re: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory

Hi Ivan, On 4/04/2018 10:01 AM, Ivan Gerasimov wrote: Hi David! On 4/3/18 4:49 PM, David Holmes wrote: Hi Ivan, On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: Hello! Yet another occurrence of not-optimally pre-sized HashMap. When java.lang.Class.enumConstantDirectory is created, the initial

Re: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory

Hi Ivan, On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: Hello! Yet another occurrence of not-optimally pre-sized HashMap. When java.lang.Class.enumConstantDirectory is created, the initial capacity is set to be (2 * universe.length), which is more than necessary in some cases. Choosing the

Re: RFR: Here are some Thread cleanup patches

load, and the experiment above supports that. The initialization order can be quite different to the load order. David On Tue, Mar 27, 2018 at 6:59 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: On 28/03/2018 11:50 AM, Martin Buchholz wrote: On T

Re: RFR: Here are some Thread cleanup patches

On 28/03/2018 11:50 AM, Martin Buchholz wrote: On Tue, Mar 27, 2018 at 6:24 PM, Martin Buchholz > wrote:  At least the VM doesn't have to run any risky java code ??  Why is Martin so sure ?? Let's check: java -Xlog:class+load=trace

Re: RFR: Here are some Thread cleanup patches

On 28/03/2018 10:48 AM, Martin Buchholz wrote: On Tue, Mar 27, 2018 at 4:42 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: Hi Martin, 8200123: Replace Thread.init with telescoping constructor http://cr.openjdk.java.net/~ma

Re: RFR: Here are some Thread cleanup patches

Hi Martin, On 28/03/2018 4:28 AM, Martin Buchholz wrote: The usual story when I change Thread.java is that I'm missing something and I end up reverting, so I was extra careful this time. 8200122: Remove unused field Thread.threadQ http://cr.openjdk.java.net/~martin/webrevs/jdk/Thread-threadQ/

Re: RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull

Hi Claes, This seems reasonable. Clearing the exception only when speculatively resolving is reasonable (it's similar to compilation clearing exceptions and falling back to interpreted mode). Thanks, David On 27/03/2018 4:49 PM, Claes Redestad wrote: On 2018-03-26 17:51, Claes Redestad

Re: RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull

On 26/03/2018 11:31 PM, Claes Redestad wrote: On 2018-03-26 15:16, David Holmes wrote: MethodHandles::resolve_MemberName doesn't "catch" exceptions from LinkResolver. They remain pending and will be thrown later unless replaced with a different exception - which sounds like wh

Re: RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull

Hi Claes, On 26/03/2018 10:08 PM, Claes Redestad wrote: Hi, MethodHandleNatives::resolve are used by both MemberName$Factory::resolveOrFail and ::resolveOrNull, the latter allowing speculative lookup of methods. While the linkResolver code this calls into in the VM will create and throw

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

On 23/03/2018 12:18 AM, Kumar Srinivasan wrote: David, Why would the VM emit these warnings if the deprecated vm flag is not being used ? The warnings are not deprecation warnings. The warnings are for flags that should have been made obsolete in this version but are still present. It is a

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

On 22/03/2018 12:52 PM, Andrei Nazarov wrote: On Mar 21, 2018 19:13, David Holmes <david.hol...@oracle.com> wrote: Hi Andrei, On 22/03/2018 11:12 AM, Andrey Nazarov wrote: > Hi, > > Please review fix in launcher tests. > > Review: http:

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

Hi Andrei, On 22/03/2018 11:12 AM, Andrey Nazarov wrote: Hi, Please review fix in launcher tests. Review: http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196750?filter=-1 test/jdk/tools/launcher/ToolsOpts.java I don't understand how

Re: RFR 8199756 : Simplify language, country, script, and variant property initialization

Hi Roger, On 19/03/2018 11:55 PM, Roger Riggs wrote: Hi Alan, The original changeset [1] is most easily viewed in the jdk-8u repo. The comment and placement of the removes of the properties and the code to re-set them around the call to the JVM_InitProperties (which sets properties from the

Re: RFR (XS): 8199768 jdk/test/lib/compiler/CompilerUtils.java needs to provide more control over compilation

Thanks for looking at this Alan! On 20/03/2018 3:23 AM, Alan Bateman wrote: On 19/03/2018 05:11, David Holmes wrote: Unsure exactly who should review this ... bug: https://bugs.openjdk.java.net/browse/JDK-8199768 webrev: http://cr.openjdk.java.net/~dholmes/8199768/webrev

Re: RFR (XS): 8199768 jdk/test/lib/compiler/CompilerUtils.java needs to provide more control over compilation

Thanks Paul! David On 20/03/2018 3:18 AM, Paul Sandoz wrote: Looks ok, +1 Paul. On Mar 18, 2018, at 10:11 PM, David Holmes <david.hol...@oracle.com> wrote: Unsure exactly who should review this ... bug: https://bugs.openjdk.java.net/browse/JDK-8199768 webrev: http://cr.openjdk.ja

RFR (XS): 8199768 jdk/test/lib/compiler/CompilerUtils.java needs to provide more control over compilation

Unsure exactly who should review this ... bug: https://bugs.openjdk.java.net/browse/JDK-8199768 webrev: http://cr.openjdk.java.net/~dholmes/8199768/webrev/ CompilerUtils.compile compiles all source files in a given directory tree into a specific directory. This is done by passing

Re: [PATCH] 8188240: Reflection Proxy should skip static methods

On 15/03/2018 5:56 PM, Peter Levart wrote: Hi Aleksey, In test, the following comment:   26  * @summary This is a test to ensure that proxies do not inherit static methods. I think the word "inherit" is not correct here. Interface static methods can not be inherited. VM already ensures

Re: RFR JDK-8196748,tools/jar tests need to tolerate unrelated warnings

Hi Sherman, On 13/03/2018 5:13 AM, Xueming Shen wrote: On 3/11/18, 7:48 PM, David Holmes wrote: Hi Sherman, Thanks for working on this and adding the new functionality to OutputAnalyzer, but note that: +   private static final String jvmwarningmsg = +   "Java HotSpot\\(TM\\) 6

Re: RFR JDK-8196748,tools/jar tests need to tolerate unrelated warnings

Hi Sherman, On 10/03/2018 8:34 AM, Xueming Shen wrote: Hi, Please help codereview the change for JDK-8196748. Issue: https://bugs.openjdk.java.net/browse/JDK-8196748 webrev: http://cr.openjdk.java.net/~sherman/8196748/webrev Those tests are based on parsing the std in/err of the jar command.

Re: core-libs-dev Digest, Vol 131, Issue 26

"A Z", Can you please post using appropriate subject lines, and formatting and follow basic email etiquette - which includes identifying yourself. You are quoting 20 year old papers. The JavaGrande effort was born in 1998 and died a few years later. David On 7/03/2018 9:38 AM, A Z wrote:

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

Hi Ian, Do you run with -Xcheck:jni in production mode because you load unknown native code libraries? It's mainly intended as a diagnostic option to turn on if you encounter a possible JNI problem. I'll leave the debate on your actual patch proposal to others more familiar with the

Re: RFR 8198970: jnu_util.c compilation error on Solaris

On 3/03/2018 8:56 AM, Roger Riggs wrote: Please review a correction to the jni_util.c native code that does not compile on Solaris. Declarations must precede assignments. Wow! I didn't think Solaris Studio compiler was subject to such anachronisms! We must be compiling in a really old mode.

Re: RFR: Here are some URLClassPath patches

On 2/03/2018 2:59 PM, Martin Buchholz wrote: I have a patch to move those old jdi tests out of the ProblemList jail. I thought we had an existing bug in hotspot-svc to do this, but now I can't find it. I've created a sub-task of 8198803 for this and assigned it to you.

Re: RFR: Here are some URLClassPath patches

On 2/03/2018 2:21 PM, Martin Buchholz wrote: Ops. 8198810 is the id of the CSR, not the real bug - I should have used 8198803. So I may have broken a jira invariant. Probably jcheck should have caught my mistake. What now? Now you have to manually update the real bug with the changeset

Re: RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck

Hi Sherman, On 24/02/2018 11:26 AM, Xueming Shen wrote: Hi, Please help review the proposed change to remove the potential performance bottleneck in CoderResult caused by the "over" synchronization the cache mechanism. issue: https://bugs.openjdk.java.net/browse/JDK-8187653 webrev:

Re: RFR: Here are some URLClassPath patches

Looks good. Thanks, David On 28/02/2018 3:03 PM, Martin Buchholz wrote: 8198808: jdi tests failing after JDK-8198484 http://cr.openjdk.java.net/~martin/webrevs/jdk/jdi-ProblemList/ https://bugs.openjdk.java.net/browse/JDK-8198808

Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

On Feb 26, 2018, at 9:00 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: Hi Igor, On 27/02/2018 11:25 AM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html 9 lines changed: 2 ins; 0 del; 7 mod; Hi al

Re: RFR: Here are some URLClassPath patches

Hi Martin, On 28/02/2018 1:02 PM, Martin Buchholz wrote: I should probably do more testing than usual when touching classloading... We have a jdi test that does this (hg blame finds duke as only author):     public static ClassLoader classLoaderValue;     {         try {            

Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

Hi Igor, On 27/02/2018 11:25 AM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html 9 lines changed: 2 ins; 0 del; 7 mod; Hi all, could you please review the patch for TimSortStackSize2 test? the test failed when externally passed (via -javaoption or

Re: [11] RFR JDK-8198653: ClassLoader::getSystemClassLoader throws InternalError when called after shutdown

Looks good. Is there an existing test that caught this? Thanks, David On 24/02/2018 7:57 AM, mandy chung wrote: JDK-8198249 added a new shutdown VM initLevel. ClassLoader::getSystemClassLoader should be updated to handle the new case.  I checked all other callers of VM::initLevel and no

Re: RFR: 8197901: Crash during GC when logging level is debug

Hi Leonid, Looks fine. Please also add this bug id to @bug in test/jdk/java/lang/StackWalker/VerifyStackTrace.java Thanks, David On 23/02/2018 12:41 PM, Leonid Mesnik wrote: Hi Could you please review following fix which update implementation of Klass::external_name for anonymous classes.

Re: [11] RFR JDK-8198441: Replace native Runtime::runFinalization0 method with shared secrets

Looks good. Thanks, David On 21/02/2018 3:45 AM, mandy chung wrote: Webrev:   http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198441/webrev.00 This is a small cleanup that replaces the native Runtime::runFinalization0 method with shared secrets to invoke Finalizer::runFinalization in java.

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, On 22/02/2018 12:28 PM, mandy chung wrote: On 2/21/18 6:08 PM, David Holmes wrote: Hi Mandy, tl;dr: I think this is now good to go. On 22/02/2018 5:58 AM, mandy chung wrote: Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/ I added

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

nExitHook are two other system shutdown hooks to restore console echo state or support deleteOnExit. The system shutdown hooks are all run in the thread initiating the shutdown that holds the Shutdown.class. On 2/20/18 10:27 PM, David Holmes wrote: Hi Mandy, On 21/02/2018 5:57 AM, mandy chu

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

c and the implementation. So apologies but what started out as a seemingly simple code removal, has become a lot more complicated, and confusing to me. Thanks, David - On 2/15/18 9:14 PM, David Holmes wrote: All other updates seem okay. I did have one further thought - in Runtime doe

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 16/02/2018 10:12 PM, Alan Bateman wrote: On 16/02/2018 04:09, mandy chung wrote: Merged.  New version: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/ Good to see this change. One comment on Runtime.exec is that the 3rd paragraph of the updated spec is difficult to

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, On 16/02/2018 1:20 PM, mandy chung wrote: On 2/15/18 6:11 PM, David Holmes wrote: Hi Mandy, Good to see this go. A few minor comments. First I've added comments on the CSR as some of the doc changes don't read correctly. Thanks for catching it.  What do you think about

Re: RFR: 8041626: [Event Request] Shutdown reason

wrote: On 12/02/2018 07:07, David Holmes wrote: Okay, I’ve removed the code related to the status field, certainly makes the change a bit less intrusive. Updated webrev: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.01/ Incremental: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.0

Re: JEP [DRAFT]: Container aware Java

On 16/02/2018 4:30 AM, kedar mhaswade wrote: This appears useful. Will Runtime.getRuntime().availableProcessors() return the processors available to the container after this integration, or will a new API be provided? I have seen thread pools being misconfigured (e.g. it returns the number of

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, Good to see this go. A few minor comments. First I've added comments on the CSR as some of the doc changes don't read correctly. src/hotspot/share/runtime/thread.cpp This comment doesn't read correctly: ! // won't be run. Note that if a shutdown hook was registered //

Re: 8193818 : Remove unused single_step field from java.lang.Thread

On 15/02/2018 9:42 PM, Alan Bateman wrote: On 19/12/2017 11:06, Alan Bateman wrote: I've been going through the fields in java.lang.Thread and I'm wondering if this field can be removed:     /* Whether or not to single_step this thread. */     private boolean single_step; This field was

Re: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java

On 15/02/2018 12:13 AM, Adam Farley8 wrote: Hi All, -- Short version -- Could a committer please take the fix for JDK-8190187 (full code included in the bug) and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain (a) the new return code, and (b) the

Re: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)

That all seems trivially fine. Thanks, David On 15/02/2018 7:45 AM, sangheon.kim wrote: Hi all, Could I have some reviews for CMM removal? This is closed CR but some public codes also need small modifications. This CR is for removing stuff related to an Oracle JDK module/package. Changes are

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

On 14/02/2018 10:43 PM, David Holmes wrote: Adding in core-libs-dev as there's nothing related to hotspot directly here. Correction, this is of course leading to a proposed change in hotspot to implement the new Unsafe methods and perform the native memory tracking. Of course we already have

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

Adding in core-libs-dev as there's nothing related to hotspot directly here. David On 14/02/2018 9:32 PM, Adam Farley8 wrote: Hi All, Currently, diagnostic core files generated from OpenJDK seem to lump all of the native memory usages together, making it near-impossible for someone to figure

Re: RFR 8190378: Java EE and CORBA modules removal

Lance, In Docs.gmk you seem to have missed this: 445 446 # Setup generation of the Java SE API documentation (javadoc + modulegraph) 447 448 # The Java SE module scope is just java.se.ee and its transitive

Re: IllegalAccessException trying to load a ResourceBundle in 9u181

Hi Vitaly, See this thread: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-February/013584.html David On 13/02/2018 6:36 AM, Vitaly Davidovich wrote: Hi all, I'm not sure if core-libs is the right mailing list for jigsaw/modules questions these days (rather than jigsaw-dev), so

Re: RFR 8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options

oracle.com <mailto:harold.sei...@oracle.com>> wrote: Hi Alan, Thanks for looking at this. Harold On 2/12/2018 2:52 AM, Alan Bateman wrote: On 12/02/2018 06:54, David Holmes wrote: Hi Harold, Adding core-libs-dev so they are aware of the ClassLoader change. Thanks, that part is okay and good to see this going away. -Alan

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, On 10/02/2018 1:41 AM, Robin Westberg wrote: Hi David, On 9 Feb 2018, at 05:22, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: Hi Robin, Right, almost all the runtime changes are made in order to try to figure out what the process ex

Re: RFR 8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options

can be debug-only. Thanks, David - And, please see in-line comments. On 2/8/2018 5:42 PM, David Holmes wrote: Hi Harold, First I'm pretty sure this one can't be pushed until the version bump arrives in jdk/hs :) I hope the version bump arrives soon. On 9/02/2018 6:53 AM, h

Re: RFR: jsr166 jdk integration 2018-02

On 9/02/2018 3:35 PM, Martin Buchholz wrote: On Thu, Feb 8, 2018 at 8:39 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: Wow! DelegatedExecutorService doesn't even have a finalize() method that does a shutdown. So we have to put the reach

Re: RFR: jsr166 jdk integration 2018-02

Hi Martin, On 9/02/2018 2:07 PM, Martin Buchholz wrote: On Thu, Feb 8, 2018 at 7:39 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: On 9/02/2018 11:19 AM, Martin Buchholz wrote: http://cr.openjdk.java.net/~martin/webrev

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, On 9/02/2018 1:50 AM, Robin Westberg wrote: Hi David, On 8 Feb 2018, at 04:28, David Holmes <david.hol...@oracle.com> wrote: Hi Robin, Adding in hotspot-runtime-dev as all the hotspot changes belong to runtime. Thanks, sorry about that.. I had an initial look t

Re: RFR: jsr166 jdk integration 2018-02

On 9/02/2018 11:19 AM, Martin Buchholz wrote: http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8190324: ThreadPoolExecutor should not specify a dependency on finalization

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Moving to core-libs-dev. Code reviews don't take place on jdk-dev but on the component area mailing lists. Thanks, David On 8/02/2018 6:10 AM, yumin qi wrote: Hi, Please review the fix (extra small) for: bug 8194154: https://bugs.openjdk.java.net/browse/JDK-8194154 webrev:

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, Adding in hotspot-runtime-dev as all the hotspot changes belong to runtime. I had an initial look through this. To be honest I don't like it. We seem to have to record little bits of information all over the place just so they can be reported by the shutdown event. It seems untidy.

Re: [PATCH] GPU Exploitation Infrastructure

Project Sumatra was looking at GPU use: https://wiki.openjdk.java.net/display/Sumatra/Main It's inactive though. David On 31/01/2018 7:46 AM, David Holmes wrote: On 31/01/2018 1:35 AM, Alan Bateman wrote: On 30/01/2018 13:55, Ben Walsh wrote: This patch provides the infrastructure to enable

Re: [PATCH] GPU Exploitation Infrastructure

On 31/01/2018 1:35 AM, Alan Bateman wrote: On 30/01/2018 13:55, Ben Walsh wrote: This patch provides the infrastructure to enable the exploitation of a GPU by the compiler to accelerate certain suitable Java constructs. When enabled, a suitable compiler can attempt to accelerate the following

Re: [11] RFR JDK-8196127: Dead code in VersionProps.java.template

Wow that was fast! :) Looks good. Thanks, David On 26/01/2018 5:33 AM, mandy chung wrote: Trivial fix to remove unused isHeadless variable. $ hg diff src/java.base/share/classes/java/lang/VersionProps.java.template diff --git

Re: RFR(XS): 8195824: tools/launcher/HelpFlagsTest.java fails with java.lang.AssertionError

Hi Goetz, On 23/01/2018 5:36 PM, Lindenmaier, Goetz wrote: Hi, javacpl seems not to have a help message, so it just needs to be excluded from the test. Please review. http://cr.openjdk.java.net/~goetz/wr18/8195824-fixHelpTest2/webrev/ That seems okay. Did you test it on Windows? Also ...

Re: JDK 11 RFR of JDK-8195987,,Problem list tools/launcher/HelpFlagsTest.java fails on windows

Looks good! I hope this is the last failure we see from this one! Thanks, David On 23/01/2018 4:53 PM, joe darcy wrote: Hello, The test     tools/launcher/HelpFlagsTest.java has been failing on windows (JDK-8195824) since the push for JDK-8195663. The test needs to be problem listed on

Re: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

Thanks Bob. Seems okay. David On 23/01/2018 3:20 AM, Bob Vandette wrote: Please review this change that resolves the detection of Java processes that are running in cgroup based containers. This latest (and hopefully final) update of this fix addresses comments from David Holmes and Mandy

Re: RFR of 8194284: CheckRegisterInLog.java fails with java.lang.RuntimeException: CheckRegisterInLog got exception timeout 6480000ms out of range

Hi Hamlin, On 19/01/2018 4:28 PM, Hamlin Li wrote: On 19/01/2018 2:11 PM, David Holmes wrote: Hi Hamlin, On 19/01/2018 3:04 PM, Hamlin Li wrote: Hi Roger, David Please check the updated webrev at: http://cr.openjdk.java.net/~mli/8194284/webrev.00/ RMID.java: This comment no longer

Re: RFR of 8194284: CheckRegisterInLog.java fails with java.lang.RuntimeException: CheckRegisterInLog got exception timeout 6480000ms out of range

Hi Hamlin, On 19/01/2018 3:04 PM, Hamlin Li wrote: Hi Roger, David Please check the updated webrev at: http://cr.openjdk.java.net/~mli/8194284/webrev.00/ RMID.java: This comment no longer makes sense: // when restart rmid, it may take more time than usual because of // "port

Re: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails with java.lang.AssertionError: HelpFlagsTest failed:

Hi Goetz, On 19/01/2018 2:24 AM, Lindenmaier, Goetz wrote: Posting this to core-libs-dev. Please review http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.02/ which excludes the Oracle proprietary tools from the test. I can not verify this. Wouldn't a whitelist work better

Re: RFR of 8194284: CheckRegisterInLog.java fails with java.lang.RuntimeException: CheckRegisterInLog got exception timeout 6480000ms out of range

On 18/01/2018 7:21 PM, Hamlin Li wrote: On 18/01/2018 5:07 PM, David Holmes wrote: On 18/01/2018 6:05 PM, Hamlin Li wrote: On 18/01/2018 3:48 PM, David Holmes wrote: On 18/01/2018 5:41 PM, Hamlin Li wrote: Hi David, Sometime we will run test by command "jtreg -timeoutFactor:xxx ...&

<    5   6   7   8   9   10   11   12   13   14   >