Re: JDK-8036003: Add variable not to separate debug information.

The proper way to fix this is to disable FDS. We should not need yet another option to control debug info. Dan On 2/28/14 4:13 AM, David Holmes wrote: Hi, As I put in the bug report this seems way too complicated. Seems to me all you need to do to get what you want is not use FDS and not

Re: JDK-8036003: Add variable not to separate debug information.

I think we're having a problem with not all replies making it to all the aliases. Yasumasa's reply to David below that Mike is replying to did not arrive on any of the aliases that I'm on... Folks need to remember to reply to all of the aliases... On 3/1/14 4:08 PM, Mike Duigou wrote: On Mar 1

Re: JDK-8036003: Add variable not to separate debug information.

On 3/3/14 12:11 PM, Omair Majid wrote: Hi, * Daniel D. Daugherty daniel.daughe...@oracle.com [2014-03-03 09:57]: On 3/1/14 4:08 PM, Mike Duigou wrote: If we can put debuginfo into external files why would we ever want unstripped binaries? We deliver minimal stripped binaries so that can

Re: JDK-8036003: Add variable not to separate debug information.

On 3/3/14 2:49 PM, Omair Majid wrote: * David Holmes david.hol...@oracle.com [2014-02-28 18:48]: There are three pieces to all of this: 1. Generating debug symbols in the binaries (via gcc -g or whatever) 2. Generating debuginfo files (zipped or not) (FDS) 3. Stripping debug symbols from the

Re: JDK-8036003: Add variable not to separate debug information.

On 3/17/14 7:19 PM, Andrew Hughes wrote: - Original Message - On 3/3/14 2:49 PM, Omair Majid wrote: * David Holmes david.hol...@oracle.com [2014-02-28 18:48]: There are three pieces to all of this: 1. Generating debug symbols in the binaries (via gcc -g or whatever) 2. Generating

Re: JDK-8036003: Add variable not to separate debug information.

On 3/18/14 12:22 PM, Andrew Hughes wrote: - Original Message - On 3/17/14 7:19 PM, Andrew Hughes wrote: - Original Message - On 3/3/14 2:49 PM, Omair Majid wrote: * David Holmes david.hol...@oracle.com [2014-02-28 18:48]: There are three pieces to all of this: 1. Generating

Re: XS RFR: 8002040 Allow Full Debug Symbols when cross-compiling

On 11/6/12 10:08 PM, David Holmes wrote: webrev: http://cr.openjdk.java.net/~dholmes/8002040/webrev/ Thumbs up. make/common/Defs-linux.gmk No comments. This is a simplified variant of the change just made to Hotspot. Instead of disabling FDS when cross-compiling we change the default

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

For this item: test/java/util/logging/LoggingDeadlock4.java Test case was simplified to avoid AWT class loading. Negative test result was tested on early JDK7 build. if I remember correctly, the whole point of that test was to check for a logging deadlock relative to

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

On 12/12/12 9:47 AM, Alan Bateman wrote: On 12/12/2012 16:36, Daniel D. Daugherty wrote: For this item: test/java/util/logging/LoggingDeadlock4.java Test case was simplified to avoid AWT class loading. Negative test result was tested on early JDK7 build. if I remember

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

On 12/13/12 2:35 AM, Alexey Utkin wrote: On 12.12.2012 20:52, Daniel D. Daugherty wrote: On 12/12/12 9:47 AM, Alan Bateman wrote: On 12/12/2012 16:36, Daniel D. Daugherty wrote: For this item: test/java/util/logging/LoggingDeadlock4.java Test case was simplified to avoid AWT

Re: Define JNIEXPORT as visibility default with GCC?

I couldn't find a 'jdk' repo relevant bug for this issue so I filed: 8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's jni_md.h needs similar change http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008509

Re: Define JNIEXPORT as visibility default with GCC?

On 2/28/13 11:57 AM, David DeHaven wrote: Has a bug been filed for this? -DrD- As mentioned earlier in this thread... Dan On 2/19/13 5:21 PM, Daniel D. Daugherty wrote: I couldn't find a 'jdk' repo relevant bug for this issue so I filed: 8008509: 6588413 changed JNIEXPORT visibility

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

On 7/3/13 11:12 AM, Ivan Gerasimov wrote: Hello everybody! We have a request to improve jtreg test. The test had been written to verify fix for memory leak during class redefinition. The problem is that it always is reported as PASSED even in the presence of the leak. The proposed change is

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

to include this into this same change set or should I make it separately? I would include it in the same changeset. Dan Sincerely yours, Ivan On 04.07.2013 19:34, Daniel D. Daugherty wrote: On 7/3/13 11:12 AM, Ivan Gerasimov wrote: Hello everybody! We have a request to improve jtreg test

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

/8016838-jdk8-ReBigClass-improved.patch Thanks in advance, Ivan On 04.07.2013 21:45, Daniel D. Daugherty wrote: On 7/4/13 11:19 AM, Ivan Gerasimov wrote: Daniel, thank you for review! Here's the updated with all all your suggestions adopted. http://cr.openjdk.java.net/~igerasim/8016838/1

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch Thanks in advance, Ivan On 04.07.2013 21:45, Daniel D. Daugherty wrote: On 7/4/13 11:19 AM, Ivan Gerasimov wrote: Daniel, thank you for review! Here's the updated with all all your suggestions adopted. http://cr.openjdk.java.net/~igerasim

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

a link to hg export: http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch Thanks in advance, Ivan On 04.07.2013 21:45, Daniel D. Daugherty wrote: On 7/4/13 11:19 AM, Ivan Gerasimov wrote: Daniel, thank you for review! Here's the updated with all all your suggestions

Re: RFR: Remove tests from ProblemList.txt

On 8/22/13 5:32 AM, David Holmes wrote: On 22/08/2013 12:20 AM, Staffan Larsen wrote: I've had a look at these two old bugs: http://bugs.sun.com/view_bug.do?bug_id=7020857 http://bugs.sun.com/view_bug.do?bug_id=6909804 They are both listed in ProblemList.txt and reported as intermittent

Re: RFR(S): 7200277 [parfait] potential buffer overflow in npt/utf.c

On 9/20/13 3:49 AM, Staffan Larsen wrote: Please review this change to avoid a buffer overflow in npt/utf.c. webrev: http://cr.openjdk.java.net/~sla/7200277/webrev.00/ Thumbs up. src/share/npt/utf.c No comments Dan bug: https://bugs.openjdk.java.net/browse/JDK-7200277 Thanks,

Re: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV

http://cr.openjdk.java.net/~coleenp/8025238/ src/share/vm/classfile/javaClasses.cpp 1804 if (method == NULL) { 1805 // leave name and fileName null 1806 java_lang_StackTraceElement::set_lineNumber(element(), -1); Is it possible to set the name and fileName to

Re: Review Request (1-line fix): 7032589 FileHandler leaking file descriptor of the file lock

Thumbs up. Dan On 4/15/2011 11:01 AM, Mandy Chung wrote: Fix for 7032589: FileHandler leaking file descriptor of the file lock Webrev at: http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/ When a log file is currently being used, tryLock() will fail and it has to close the file

Re: Review Request (1-line fix): 7032589 FileHandler leaking file descriptor of the file lock

On 4/15/2011 1:12 PM, Mandy Chung wrote: Hi Remi, On 04/15/11 11:05, Rémi Forax wrote: Hi Mandy, if fc.close() throws an IOException , it goes wrong. I think you need to put fc.close() in its own a try/catch(IOException). That's a good point. I think it should throw IOException if

Re: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR)

On 8/4/11 9:50 AM, Alan Bateman wrote: David Buck wrote: Hi! I would like to request that my fix for 7011591 be reviewed for push into JDK8 (and JDK7u if possible). CR: 7011591 JDWP socket transport should restart interrupted system calls (EINTR) : Webrev:

Re: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin

On 8/9/11 8:52 AM, Chris Hegarty wrote: Hi Dan, Alan, This is a trivial change to use /dev/null instead of NUL for Windows test with Cygwin. http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/ Thanks, -Chris. I'm good with the change, but the bug report itself is less than clear.

Re: Fwd: Code Review 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win)

On 8/9/11 8:29 AM, Chris Hegarty wrote: Sorry, should have cc'ed serviceability-...@openjdk.java.net too. -Chris. Original Message Subject: Code Review 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win) Date: Tue, 09 Aug 2011 14:05:08 +0100

Re: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin

/jdi tests in a batch, in samevm mode, this test leave behind a file, NUL, in the scratch directory that cannot be deleted. This causes the remaining tests to also fail. Thanks for the review, -Chris. On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote: On 8/9/11 8:52 AM, Chris Hegarty wrote: Hi

Re: Fwd: Code Review 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win)

Thanks for closing the loop. The changes are good as is. Dan On 8/9/11 2:02 PM, Chris Hegarty wrote: On 08/ 9/11 05:11 PM, Daniel D. Daugherty wrote: On 8/9/11 8:29 AM, Chris Hegarty wrote: Sorry, should have cc'ed serviceability-...@openjdk.java.net too. -Chris. Original Message

Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale

Just FYI: I haven't seen Éamonn's posting come in. Just replies to his posting. This may mean that other comments are stuck in the ether somewhere... I suspect that the OpenJDK list server is again having issues... Dan On 2/24/12 8:21 AM, Olivier Lagneau wrote: I think I have not been clear

Re: RFR: 7134701 [macosx] Support legacy native library names

On 3/27/12 8:05 AM, Michael McMahon wrote: JDK 8 fix for this issue. For readers not familiar with Mac OS, this is to fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 initial port. The preferred native library file suffix is .dylib on Mac, but some legacy libraries use the

Re: RFR: 7134701 [macosx] Support legacy native library names

On 3/27/12 12:46 PM, Michael McMahon wrote: On 27/03/12 16:03, Daniel D. Daugherty wrote: On 3/27/12 8:05 AM, Michael McMahon wrote: JDK 8 fix for this issue. For readers not familiar with Mac OS, this is to fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 initial port

Re: RFR: 7134701 [macosx] Support legacy native library names

On 3/27/12 3:23 PM, Michael McMahon wrote: Could I get the following webrev for 7u4 reviewed please? It is the same code change as for jdk 8 http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ Thanks, Michael. Thumbs up. Dan make/java/java/FILES_java.gmk

Re: RFR: 7134701 [macosx] Support legacy native library names

On 3/28/12 3:52 AM, Michael McMahon wrote: On 28/03/12 08:40, Alan Bateman wrote: On 28/03/2012 04:51, Scott Kovatch wrote: With this patch in place I can load the applet at Runescape.com now. I can't log in yet due to an AWT bug I probably haven't patched yet, but this is better than what it

Re: RFR: 7134701 [macosx] Support legacy native library names

On 3/29/12 4:25 AM, Michael McMahon wrote: On 27/03/12 22:23, Michael McMahon wrote: Could I get the following webrev for 7u4 reviewed please? It is the same code change as for jdk 8 http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ Thanks, Michael. I've updated the webrev for

Re: Review request for 6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE

Mandy Chung wrote: Dan, Can you review the fix for: 6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE Webrev at: http://cr.openjdk.java.net/~mchung/6924497/webrev.00/ src/share/classes/sun/management/Flag.java line 95 - I don't local var 'c' is needed here or on line 99.

Re: Review request: test/java/util/logging/ParentLoggersTest.java fails in samevm mode

Mandy, What happens when the test is run twice in samevm mode? I suspect that the expected Logger names will be in the initialLoggerNames list at the beginning of the second run and thus won't be added to returnedLoggerNames on line 104. There isn't a way to delete a Logger so if you want this

Re: Review request: test/java/util/logging/ParentLoggersTest.java fails in samevm mode

OK by me. Forgot to say thumbs up before. Dan On 6/16/2010 6:41 PM, Mandy Chung wrote: Daniel D. Daugherty wrote: Mandy, What happens when the test is run twice in samevm mode? The test only needs to support running once in samevm mode. Are you thinking of some kind of stress testing

Re: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid

The default JTreg time out is 5 minutes... I believe the default JTREG timeout is 120 seconds or 2 minutes. Dan On 12/17/14 6:11 AM, Yekaterina Kantserova wrote: Hopefully the last version :) Erik has recommended to skip the whole timeout concept. Instead the test will loop until a

Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General comment: Not all copyright years were updated. General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's

Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: Hi Daniel, Thank you for your thorough review! This was my (failing) attempt at a fast pass review... :-) On 2015-06-09 01:31, Daniel D. Daugherty wrote: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General

Re: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version"

On 11/3/15 10:45 AM, Alejandro E Murillo wrote: Please review these changes: bug: https://bugs.openjdk.java.net/browse/JDK-8139986 Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ jdk/src/java.base/share/classes/sun/misc/Version.java.template nit: L103: if

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

t; this one also might be a tab Thumbs up! I do not need to see a webrev for the above nits. Dan On 24/11/2015 17:26, Daniel D. Daugherty wrote: src/cpu/sparc/vm/frame_sparc.cpp (old) L635: if (fp() - sp() > 1024 + m->max_stack()*Interpreter::stackElementSize) { (new)

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

On 11/24/15 1:52 PM, Mandy Chung wrote: The value of anchor is an address and it’s an unsigned value. The check should be fixed to handle unsigned value. diff --git a/src/java.base/share/classes/java/lang/StackStreamFactory.java b/src/java.base/share/classes/java/lang/StackStreamFactory.java

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On 11/23/15 10:44 AM, Frederic Parain wrote: Karen, Thank you for your review, my answers are in-lined below. New Webrevs (including some fixes suggested by Paul Sandoz): http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ src/cpu/sparc/vm/frame_sparc.cpp (old) L635: if

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ make/mapfiles/libjava/mapfile-vers No comments. src/java.base/share/classes/java/lang/ref/Reference.java Much cleaner (pun might have been intended :-)). src/java.base/share/native/include/jvm.h No comments.

Re: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9

On 1/27/16 4:02 PM, Rachel Protacio wrote: Hello! Small but important change for review: updating the JNI_VERSION and in so doing, changing the format from JNI_VERSION_1_x to JNI_VERSION_x_y (see code/bug for details). Bug: https://bugs.openjdk.java.net/browse/JDK-8145098 hotspot repo

Re: ClassFileTransformer does not apply to anonymous classes

On 1/22/16 7:29 AM, Alan Bateman wrote: On 22/01/2016 14:00, Coleen Phillimore wrote: Can you send the question again? I didn't see it. I also mostly look at JVM code and rarely deal with the Java side. The question was asked about ClassFileTransformer which is implemented by the JPLIS

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 4/28/16 5:09 PM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8154710 webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ src/os/solaris/vm/os_solaris.cpp L1356: static _get_nsec_fromepoch_func_t _get_nsec_fromepoch = NULL; nit: two spaced between

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

Paul, I have marked this bug (JDK-8162458) as an 'integration_blocker' in order to keep JDK-8151163 from leaving JDK9-hs in its current state. Dan On 7/28/16 4:33 AM, Paul Sandoz wrote: Hooking in nio dev. I think this issue is important to review/push soon (i.e. this week) so as it does

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

On 12/8/16 1:59 PM, David Holmes wrote: On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: Hi David, thanks for looking at the change. New webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ src/java.base/share/native/libjli/java.c As far as I can see the existing

Re: RFR(10)(XS) 8177015: STACK_SIZE_MINIMUM of 32k is not always enough for Mac OS X

On 3/24/17 2:12 PM, Chris Plummer wrote: Hello, Please review changes for the following: http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/ > http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/webrev.hotspot/ test/runtime/Thread/TooSmallStackSize.java No comments. >

Re: RFR(10)(XS) 8177015: STACK_SIZE_MINIMUM of 32k is not always enough for Mac OS X

On 3/26/17 11:55 PM, Chris Plummer wrote: Hi David, On 3/26/17 5:06 PM, David Holmes wrote: Hi Chris, On 25/03/2017 6:12 AM, Chris Plummer wrote: Hello, Please review changes for the following: http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/

Re: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1

On 11/24/17 6:16 AM, Rahul Raghavan wrote: Hi, Please review the following fix proposal for 8191813. webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ test/hotspot/jtreg/compiler/runtime/SpreadNullArg.java     No comments. So this style of call:    

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

On 12/8/17 4:28 AM, Alan Bateman wrote: On 07/12/2017 16:55, Daniel D. Daugherty wrote: : Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https://bugs.openjdk.java.net/browse/JDK-8182307

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

/7/17 11:38 AM, Daniel D. Daugherty wrote: Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment https://bugs.openjdk.java.net/browse/JDK-8182307 The fix is copied from Jerry's work on the following

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

DK 10 enters Rampdown Phase One in one week". In short, the RDP1 deadline applies to jdk/jdk, jdk/hs and jdk/client all at the same time. Dan Thanks, Serguei On 12/7/17 09:09, Daniel D. Daugherty wrote: Roger, Thanks for the review! Dan P.S. I'm planning to push this fix to jd

Re: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

On 8/7/18 2:29 AM, Alan Bateman wrote: On 06/08/2018 17:49, Daniel D. Daugherty wrote: : +java/net/Socket/LingerTest.java 8208690 generic-all +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all

Re: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

On 8/6/18 1:41 PM, Vladimir Kozlov wrote: On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: On 8/6/18 1:14 PM, Vladimir Kozlov wrote: Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use /othervm): "Tests that don't manage their th

Re: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

On 8/6/18 1:52 PM, Vladimir Kozlov wrote: On 8/6/18 10:43 AM, Daniel D. Daugherty wrote: On 8/6/18 1:41 PM, Vladimir Kozlov wrote: On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: On 8/6/18 1:14 PM, Vladimir Kozlov wrote: Okay, I read more about what happened. I think compiler tests should

Re: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

On 8/6/18 1:41 PM, Vladimir Kozlov wrote: On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: On 8/6/18 1:14 PM, Vladimir Kozlov wrote: Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use /othervm): "Tests that don't manage their th

RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

Greetings, I'm in the process of reducing the noise in the JDK12 CI so I need a single (R)eviewer for the following fix:     JDK-8209018 ProblemList tests affected by JDK-8208690     https://bugs.openjdk.java.net/browse/JDK-8209018 Here's the diff: $ hg diff diff -r c00451b67854

Re: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

see the two compiler tests listed in different entries. The compiler test failures are intermittent, but the other two happen in every tier2... Dan Thanks, Vladimir On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: Greetings, I'm in the process of reducing the noise in the JDK12 CI so I need

Re: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690

f it? Dan Regards, Vladimir On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: On 8/6/18 12:59 PM, Vladimir Kozlov wrote: Hi Dan, 8208690 lists only next 2 tests: sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) java/net/Socket/LingerTest.java (2 instances) Why you also added

Re: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList

Daniel, Thanks for the fast review! Dan On 9/24/18 1:03 PM, Daniel Fuchs wrote: Looks good to me Dan! Let's see if the errant failure reappear... best regards, -- daniel On 24/09/2018 17:56, Daniel D. Daugherty wrote: Greetings, The following bug was used to ProblemList a couple

RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList

Greetings, The following bug was used to ProblemList a couple of tests:     JDK-8209018 ProblemList tests affected by JDK-8208690     https://bugs.openjdk.java.net/browse/JDK-8209018 Jon's fix for JTREG has been in a promoted JTREG build for a while now so it's time to remove those tests from

Re: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList

Chris, Thanks for the review. I can't list you as a reviewer since I pushed right after I got dfuch's review. Dan On 9/24/18 1:18 PM, Chris Hegarty wrote: Looks good. -Chris. On 24 Sep 2018, at 17:56, Daniel D. Daugherty wrote: Greetings, The following bug was used to ProblemList

Re: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry

On 12/19/18 9:23 AM, Alexey Ivanov wrote: Any volunteers from core-libs and serviceability to review? How about former Serviceability Team members? :-) Alan B. and I both used to be on the Serviceability Team... And Alan B. is a current member of Core Libs... > webrev:

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

Thumbs up. Dan On 5/31/19 8:02 AM, Roger Riggs wrote: +1 On 5/31/19 2:19 AM, David Holmes wrote: Hi Kim, This seems reasonable to me. Thanks, David On 31/05/2019 7:04 am, Kim Barrett wrote: On May 30, 2019, at 3:58 PM, Roger Riggs wrote: Hi Kim, To ensure you see some messages in

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

On 5/29/19 1:24 PM, Kim Barrett wrote: [I’m not completely sure where this RFR should be sent, but core-libs-dev and hotspot-dev seems likely to get reasonable coverage of those who might care.] Please review this change to the test library to add some "logging" output to tests that spawn a

Re: RFR(S): 8222518: Remove unnecessary caching of Parker object in java.lang.Thread

On 4/24/19 3:12 AM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8222518 webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/ src/hotspot/share/classfile/javaClasses.cpp     L1629:   macro(_park_blocker_offset,  k, "parkBlocker", object_signature, false);    

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

On 9/5/19 1:36 AM, David Holmes wrote: Hi Dan, With my CSR Group member hat on On 5/09/2019 8:06 am, Daniel D. Daugherty wrote: Brent, You currently have '-XX:+ClassForNameDeferLinking' as a 'product' option, but product options are harder to remove down the road. Would it be better

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Brent, You currently have '-XX:+ClassForNameDeferLinking' as a 'product' option, but product options are harder to remove down the road. Would it be better as a diagnostic option? A diagnostic option requires '-XX:+UnlockDiagnosticVMOptions' to be specified before it can be used, e.g.:    

Re: Java launcher with `--module=name[/entry-point]` fails on Windows

Forwarding over to core-libs-dev@...  I think that's where launcher issues are addressed. Bcc'ing jdk-dev@... Dan On 11/15/19 6:23 AM, Christian Stein wrote: Hi, relying on the "Note: To specify an argument for a long option, you can use either --name=value or --name value." from [0] and

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

On 12/5/19 8:00 AM, David Holmes wrote: Hi Christoph, On 5/12/2019 9:55 pm, Langer, Christoph wrote: Hi David, thanks again for your efforts. Here is a version that ran successfully through jdk-submit (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172):

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

On 12/6/19 3:04 AM, Langer, Christoph wrote: Thanks, David. I'll run the final change once again through jdk-submit befor pushing. Alan, Dan, may I consider this reviewed by either of you? Sorry I haven't done a full review on this change. I just happened to see the typo fly by... Dan

Re: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination

On 10/29/19 3:42 AM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ make/hotspot/symbols/symbols-unix     No comments.

Re: 8205132: Remove Thread.countStackFrames()

On 10/29/19 12:26 PM, Alan Bateman wrote: On 23/10/2019 08:25, Alan Bateman wrote: Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. It's was never a well-defined method and I've been unable to

Re: 8205132: Remove Thread.countStackFrames()

On 10/23/19 3:25 AM, Alan Bateman wrote: Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. It's was never a well-defined method and I've been unable to find anything that uses it. The StackWalker

RFR(T): 8240134: ProblemList javax/script/Test7.java

Greetings, I'm trying to reduce the noise in the jdk/jdk CI. I'm ProblemListing javax/script/Test7.java on all platforms due to this bug:     JDK-8239361 javax/script/Test7.java failed due to ScriptException     https://bugs.openjdk.java.net/browse/JDK-8239361 I'm using the following subtask

RFR(T): 8240134: ProblemList javax/script/Test7.java

Greetings, I'm trying to reduce the noise in the jdk/jdk CI. I'm ProblemListing javax/script/Test7.java on all platforms due to this bug:     JDK-8239361 javax/script/Test7.java failed due to ScriptException     https://bugs.openjdk.java.net/browse/JDK-8239361 I'm using the following subtask

Re: RFR(T): 8240134: ProblemList javax/script/Test7.java

Thanks for the review! Dan On 2/26/20 7:36 PM, David Holmes wrote: Looks good. Thanks, David On 27/02/2020 9:03 am, Daniel D. Daugherty wrote: Greetings, I'm trying to reduce the noise in the jdk/jdk CI. I'm ProblemListing javax/script/Test7.java on all platforms due to this bug

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

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     No comments. Thumbs up. I think this qualifies

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

On Wed, 14 Oct 2020 17:59:53 GMT, Roger Riggs wrote: >> This integration without testing with a current merge from the master and >> has caused two build failures. >> >> JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar >> >> JDK-8254775: Microbenchmark

Re: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class

On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests > locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout > for tier-1

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

On Mon, 28 Sep 2020 16:22:17 GMT, Igor Ignatyev wrote: >> test/jdk/ProblemList.txt line 859: >> >>> 857: tools/jlink/JLinkReproducibleTest.java >>> 8217166 windows-all >>> 858: tools/jlink/plugins/CompressorPluginTest.java >>> 8247407 generic-all >>>

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

> 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Update existing entry for tools/jlink/JLinkReproducibleTest.java instead of creating

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

On Mon, 28 Sep 2020 16:28:48 GMT, Yumin Qi wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Should we put this for all platforms? Nope. We're currently seeing these failures on linux-aarch64 so that's what started this ProblemListing adventure... - PR:

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 @AlanBateman - not sure if 'core-libs' was the right label to add so I figured I would ping you directly for a review. - PR:

RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 - Commit messages: - Merge branch 'master' into JDK-8253667 - Also ProblemList tools/jlink/JLinkReproducible3Test.java due to 8253688. - 8253667: ProblemList tools/jlink/JLinkReproducibleTest.java on

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

On Mon, 28 Sep 2020 16:16:08 GMT, Daniel Fuchs wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update existing entry for tools/jlink/JLinkReproducibleTest.java instead >> of

Integrated: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 This pull request has now been integrated. Changeset: 821bd08c Author:Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/

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

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. src/hotspot/os/posix/os_posix.inline.hpp     No comments.

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

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: On 5/26/20 12:59 AM, David Holmes wrote: bug: https

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

On 5/29/20 11:39 AM, Daniel Fuchs wrote: Hi, I have updated the webrev as suggested by David: http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01 test/jdk/java/util/logging/Logger/bundleLeak/BundleTest.java     No comments. Thumbs up. Dan Unless I hear any objection I'll push

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

On 7/14/20 2:09 PM, Jim Laskey wrote: Adding Daniel Begin forwarded message: *From: *Jim Laskey > *Subject: **RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)* *Date: *July 14, 2020 at 2:01:09 PM ADT *To: *core-libs-dev

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

Greetings, A trivial fix to make the validate-header Tier1 task happy. Here's the context diff: $ hg diff -r qparent diff -r c5202ed40b86 test/lib/jdk/test/lib/util/JarBuilder.java --- a/test/lib/jdk/test/lib/util/JarBuilder.java    Wed Jul 08 20:35:36 2020 +0100 +++

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

Thanks for the fast review. I was surprised that jcheck -r tip didn't flag that, but... :-) Dan On 7/8/20 5:23 PM, igor.ignat...@oracle.com wrote: LGTM, thanks for fixing, and sorry for introducing that. — Igor On Jul 8, 2020, at 2:22 PM, Daniel D. Daugherty wrote: Greetings

Re: RFR(T): 8248358: ProblemList sun/nio/ch/TestMaxCachedBufferSize.java on macOSX

meant JDK-8248358 ProblemList sun/nio/ch/TestMaxCachedBufferSize.java on macOSX On Jun 25, 2020, at 2:45 PM, Daniel D. Daugherty wrote: Greetings, I'm doing another round of reduce-the-noise in the CI in preparation for the upcoming weekend... So I have another trivial review... Here's

RFR(T): 8248358: ProblemList sun/nio/ch/TestMaxCachedBufferSize.java on macOSX

Greetings, I'm doing another round of reduce-the-noise in the CI in preparation for the upcoming weekend... So I have another trivial review... Here's the bug for the failures:     JDK-8212812 sun/nio/ch/TestMaxCachedBufferSize.java timeout     https://bugs.openjdk.java.net/browse/JDK-8212812

  1   2   3   >