Re: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

2013-11-03 Thread David Holmes
Hi Tristan, On 4/11/2013 10:49 AM, Tristan Yan wrote: Thank you Martin I had code change. I took the similar way as you do here. Please review the code change for JDK-8025198. Description: Race condition exists in the test ThrowingTasks.java. We should sync CountDownLatch.countDown and

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-03 Thread David Holmes
Hi Mandy, On 2/11/2013 7:11 AM, Mandy Chung wrote: On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote: 2013/11/1 4:15 -0700, mandy.ch...@oracle.com: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/ Looks good. Just one question: In Finalizer.java, at line 97 you look up

Re: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

2013-11-03 Thread David Holmes
On 4/11/2013 1:42 PM, Martin Buchholz wrote: On Sun, Nov 3, 2013 at 5:09 PM, David Holmes david.hol...@oracle.comwrote: Locking access to a CountDownLatch just seems inherently wrong. I get that it is the atomicity of the two calls that we want, but this still seems unpleasant. I've looked

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-03 Thread David Holmes
, obj) would that actually work? (I hadn't realized JNI calling mechanism were so limited with regards to how to select the desired method.) Thanks, David On 4/11/2013 2:45 PM, Mandy Chung wrote: On 11/3/2013 5:32 PM, David Holmes wrote: Hi Mandy, On 2/11/2013 7:11 AM, Mandy Chung wrote

Re: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

2013-11-03 Thread David Holmes
On 4/11/2013 4:40 PM, Martin Buchholz wrote: David and I might prefer a fix using AtomicInteger, but I don't think there's anything incorrect with your fix - approved. Especially if you have seen the flakiness has gone away. (I've never seen this test fail.) +1 David On Sun, Nov 3, 2013

URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

2013-11-04 Thread David Holmes
My commit pulled in a bunch of local changes that should never have been pushed (the import commit failed due to whitespace and when I re-issued the commit I didn't restrict it to the single test file). Can anyone roll this back on the actual server? Thanks, David Original Message

Re: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

2013-11-04 Thread David Holmes
On 4/11/2013 10:35 PM, Alan Bateman wrote: On 04/11/2013 12:10, David Holmes wrote: My commit pulled in a bunch of local changes that should never have been pushed (the import commit failed due to whitespace and when I re-issued the commit I didn't restrict it to the single test file). Can

URGENT: RFR 8027755 Anti-delta incorrect push for 8025198

2013-11-04 Thread David Holmes
My commit for 8025198 dragged in unintended changes to: ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk ! src/share/bin/java.c See: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc This reverts those changes: http://cr.openjdk.java.net/~dholmes/8027755/webrev/

hg: jdk8/tl/jdk: 8027755: Anti-delta incorrect push for 8025198

2013-11-04 Thread david . holmes
Changeset: 23982079ad49 Author:dholmes Date: 2013-11-04 07:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23982079ad49 8027755: Anti-delta incorrect push for 8025198 Reviewed-by: alanb ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk !

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-04 Thread David Holmes
Hi Mandy, This all seems quite reasonable to me. Two minor nits: 1. The delay ntil typo in Finalizer.java is still present. 2. In VM.java. booted need not be volatile now that it is only accessed within a locked region. Also awaitBooted might as well be void as it can only ever return true.

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-04 Thread David Holmes
On 5/11/2013 12:21 PM, Mandy Chung wrote: On 11/4/2013 6:03 PM, David Holmes wrote: Hi Mandy, This all seems quite reasonable to me. Two minor nits: 1. The delay ntil typo in Finalizer.java is still present. Missed that :( 2. In VM.java. booted need not be volatile now that it is only

Re: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java

2013-11-04 Thread David Holmes
RUNNABLE, are two completely different values! Can I suggest using S_xxx for the int states (why not an enum?). Typo: awaitArrive should be awaitAdvance Thanks, David Mandy On 10/31/2013 5:38 PM, David Holmes wrote: Hi Mandy, On 1/11/2013 5:11 AM, Mandy Chung wrote: Updated webrev

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-05 Thread David Holmes
Ship it! :) And again apologies for sending you down the wrong path on the volatile. David On 6/11/2013 6:25 AM, Mandy Chung wrote: On 11/5/2013 2:38 AM, Alan Bateman wrote: On 05/11/2013 02:21, Mandy Chung wrote: Fixed. Revised webrev at:

Re: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java

2013-11-05 Thread David Holmes
for re-review. David On 6/11/2013 7:58 AM, Mandy Chung wrote: On 11/4/2013 8:42 PM, David Holmes wrote: This looks good to me. One nit that caused me some confusion - it took me a while to realize that in transitionTo eg: 221 public void transitionTo(Thread.State tstate) throws

Re: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev)

2013-11-05 Thread David Holmes
Hi Rob, How different is this to the JDK 8 version? Thanks, David On 6/11/2013 7:24 AM, Rob McKenna wrote: .. http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ -Rob On 05/11/13 21:23, Rob McKenna wrote: Hi folks, I'd like to backport this change to JDK7. Note: this fix uses

Re: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing

2013-11-05 Thread David Holmes
Hi Mike, Won't pretend I follow all the changes, but how did you get rid of the platform-specific checks in the ProblemList ? Will jtreg figure that part out for itself? Also what is the failure mode if JT_HOME is not set and jtreg is not in the path? Should we just fail in that case before

Re: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev)

2013-11-06 Thread David Holmes
vfork() on ! * Linux and spawn() on other Unix systems, but the code to use clone() ! * and fork() remains. David - -Rob On 06/11/13 01:09, David Holmes wrote: Hi Rob, How different is this to the JDK 8 version? Thanks, David On 6/11/2013 7:24 AM, Rob McKenna wrote: .. http

Re: RFR: 7174936: several String methods claim to always create new String

2013-11-06 Thread David Holmes
Hi Stuart, On 7/11/2013 11:31 AM, Stuart Marks wrote: Hi all, Please review the following spec changes to java.lang.String. In several places the specs mention returning new strings. This is overspecified; it's sufficient to return a string that satisfies the required properties. In some

Re: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev)

2013-11-07 Thread David Holmes
via the property jdk.lang.Process.launchMechanism Thanks, David -Rob On 07/11/13 01:51, David Holmes wrote: On 6/11/2013 10:00 PM, Rob McKenna wrote: Hi David, The only difference in 5049299 is the change in the default property value in Solaris. Apologies for not making that clear

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script

2013-11-07 Thread David Holmes
On 8/11/2013 1:41 PM, Patrick Zhang wrote: Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. Now the webrev and result are attached. Please help to review. After checking the scripts in java.util, most of scripts have been finished in 8003890. So the webrev only change 2

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script

2013-11-08 Thread David Holmes
On 8/11/2013 8:13 PM, Patrick Zhang wrote: Hi Alan, I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it. My understanding is that 8019502 was originally covering this issue for a broad range of tests across different areas. They were then split out into different CRs

Re: RFR(2): 7174936: several String methods claim to always create new String

2013-11-13 Thread David Holmes
version of the String spec change. Changes from the previous version address comments made by Brent Christian and David Holmes. Specifically: - Specify copyValueOf() overloads as equivalent to corresponding valueOf() overloads. - Remove extranous changes to subSequence() method - Clarify

Re: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path'

2013-11-14 Thread David Holmes
Hi Volker, On 15/11/2013 2:35 AM, Volker Simonis wrote: Hi, I wanted to solve 8026964: Building with an IBM J9 boot jdk requires special settings for BOOT_RTJAR (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the question what the real semantics of BOOT_RTJAR is? For the

Re: RFR(2): 7174936: several String methods claim to always create new String

2013-11-14 Thread David Holmes
Hi Stuart, On 15/11/2013 9:56 AM, Stuart Marks wrote: On 11/14/13 2:04 AM, David Holmes wrote: Sorry for the delay (been enroute). Only issue I have remains the subSequence change - you can't weaken the post-condition of CharSequence.subSequence without breaking subtype substitutability

Re: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm

2013-11-14 Thread David Holmes
Hi Kumar, I don't quite see how this gets the jre part of a JDK: ! JAVA_JRE_BIN = new File(JAVAHOME, bin).getAbsolutePath(); ! ! File libDir = (isSDK) ! ? new File((new File(JAVAHOME)).getParentFile(), lib) ! : new File(JAVAHOME, lib); !

Re: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects

2013-11-15 Thread David Holmes
On 15/11/2013 11:11 PM, Vitaly Davidovich wrote: +1 The amount of code in the wild that would break (if this were to change) virtually guarantees that such a change won't happen, regardless of what current spec does or does not say. It would probably be easier to just update the spec at this

Re: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path'

2013-11-15 Thread David Holmes
On 15/11/2013 8:36 PM, Volker Simonis wrote: On Fri, Nov 15, 2013 at 12:32 AM, David Holmes david.hol...@oracle.com wrote: Hi Volker, On 15/11/2013 2:35 AM, Volker Simonis wrote: Hi, I wanted to solve 8026964: Building with an IBM J9 boot jdk requires special settings for BOOT_RTJAR (https

Re: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm

2013-11-15 Thread David Holmes
On 16/11/2013 2:37 AM, Kumar Srinivasan wrote: Hi David, Hi Kumar, I don't quite see how this gets the jre part of a JDK: ! JAVA_JRE_BIN = new File(JAVAHOME, bin).getAbsolutePath(); ! ! File libDir = (isSDK) ! ? new File((new File(JAVAHOME)).getParentFile(),

Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'

2013-11-19 Thread David Holmes
Hi, Attachments are stripped. Please post on cr.openjdk.java.net (get a colleague to host this if you don't have an account yet.) Thanks, David On 19/11/2013 4:12 PM, srikalyan chandrashekar wrote: Hi all, I am working on bug JDK-6772009 https://bugs.openjdk.java.net/browse/JDK-6772009 .

Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'

2013-11-20 Thread David Holmes
On 21/11/2013 10:28 AM, Martin Buchholz wrote: I again tried and failed to reproduce a failure. Even if I go whole hog and multiply TIMEOUT by 100 and divide ITERS by 100, the test continues to PASS. Is it just me?! I think you are going the wrong way Martin - you want the timeout to be

Re: Map.merge Javadoc is confusing

2013-11-22 Thread David Holmes
a couple of issues with this particular method. David On Thu, Nov 21, 2013 at 10:53 AM, David Holmes david.hol...@oracle.comwrote: On 22/11/2013 4:17 AM, Louis Wasserman wrote: The Javadoc for Map.mergehttp://download.java.net/jdk8/docs/api/java/ util/Map.html#merge-K-V

Re: RFR: 8029055: Map.merge @implDoc is incorrect.

2013-11-24 Thread David Holmes
On Nov 22 2013, at 16:01 , Henry Jen henry@oracle.com wrote: On 11/21/2013 06:33 PM, David Holmes wrote: On 22/11/2013 5:02 AM, Louis Wasserman wrote: While I agree that case should be specified, I'm not certain I follow why that's what's going on here. The weird condition is that if oldValue

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-25 Thread David Holmes
On 26/11/2013 11:29 AM, John Rose wrote: On Nov 25, 2013, at 1:49 AM, Paul Sandoz paul.san...@oracle.com wrote: Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-26 Thread David Holmes
On 26/11/2013 9:56 PM, David Chase wrote: On 2013-11-25, at 9:18 PM, David Holmes david.hol...@oracle.com wrote: We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? Does anyone have any problems

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-26 Thread David Holmes
On 26/11/2013 10:16 PM, David Chase wrote: On 2013-11-26, at 7:12 AM, David Holmes david.hol...@oracle.com wrote: On 26/11/2013 9:56 PM, David Chase wrote: On 2013-11-25, at 9:18 PM, David Holmes david.hol...@oracle.com wrote: We do have the jdk.internal namespace. But I think Unsafe

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-26 Thread David Holmes
On 27/11/2013 2:16 AM, David Chase wrote: On 2013-11-26, at 8:12 AM, David Chase david.r.ch...@oracle.com wrote: On 2013-11-26, at 7:32 AM, David Holmes david.hol...@oracle.com wrote: On 26/11/2013 10:16 PM, David Chase wrote: On 2013-11-26, at 7:12 AM, David Holmes david.hol

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread David Holmes
On 4/12/2013 7:00 PM, Alan Bateman wrote: On 04/12/2013 08:24, Jeroen Frijters wrote: Hi, I'd like to propose to change Class.checkInitted() to check if the VM initialization has completed by using sun.misc.VM.isBooted() instead of System.out != null. This should be changed (I can only guess

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread David Holmes
On 19/12/2013 9:19 PM, Jeroen Frijters wrote: System.out can be null, because System.setOut(null) is legal. Ah I see. That isn't an initialization issue but a post-initialization issue. Thanks, David Regards, Jeroen From: David Holmes [mailto:david.hol...@oracle.com] Sent: Thursday

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread David Holmes
On 19/12/2013 9:59 PM, Alan Bateman wrote: On 19/12/2013 10:13, David Holmes wrote: Not necessarily. The question is, are there any code paths that lead to checkInitted being called after setOut0(newPrintStream(fdOut, props.getProperty(sun.stdout.encoding))) but before the call

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2013-12-19 Thread David Holmes
Hi Kalyan, This is not a hotspot issue so I'm moving this to core-libs, please drop hotspot from any replies. On 20/12/2013 6:26 AM, srikalyan wrote: Hi all, I have been working on the bug JDK-8022321 https://bugs.openjdk.java.net/browse/JDK-8022321 , this is a sporadic failure and the

Re: RFR [6968459] JNDI timeout fails before timeout is reached

2013-12-19 Thread David Holmes
If you track the elapsed waiting time using System.nanoTime you do not need to be concerned whether anyone messes with the TOD clock. David On 4/12/2013 2:05 AM, Peter Levart wrote: On 12/03/2013 03:35 PM, Ivan Gerasimov wrote: Hi Peter! Thank you for your review! You are right, the patch

Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'

2013-12-19 Thread David Holmes
inline text. On 11/20/13, 6:35 PM, David Holmes wrote: On 21/11/2013 10:28 AM, Martin Buchholz wrote: I again tried and failed to reproduce a failure. Even if I go whole hog and multiply TIMEOUT by 100 and divide ITERS by 100, the test continues to PASS. Is it just me?! I think you are going

Re: RFR for JDK-6963118 Intermittent test failure: test/java/nio/channels/Selector/Wakeup.java fail intermittently (win)

2013-12-19 Thread David Holmes
This should probably be reviewed by the nio-dev folk. Increasing the timeouts seems okay but how confident are you that this is sufficient for a wide range of platforms. In other tests we often see timeouts of a few seconds get extended even further, so three seconds is not so big. Also the

Re: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test

2013-12-19 Thread David Holmes
Hi Stuart, On 20/12/2013 1:06 PM, Stuart Marks wrote: On 12/18/13 10:25 PM, Tristan Yan wrote: Hi Everyone Please help to review the fix for JDK-8030284. http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/ http://cr.openjdk.java.net/%7Etyan/JDK-8030284/webrev.00/ This is a one line fix

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2013-12-19 Thread David Holmes
for InterruptedException. David I am still unsure about the side effects of the code change and agree with your thoughts(on memory exhaustion test's reliability). PS: hotspot dev alias removed from CC. -- Thanks kalyan On 12/19/13 5:08 PM, David Holmes wrote: Hi Kalyan, This is not a hotspot issue so I'm moving

Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'

2013-12-20 Thread David Holmes
/ . Ok. Thanks, David -- Thanks kalyan Ph: (408)-585-8040 On 12/19/13, 8:10 PM, David Holmes wrote: Sorry Kalyan but I don't see the need for all the incidental changes if the primary change is to just increase the iterations. I also don't see why you need to do anything

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-06 Thread David Holmes
Back from vacation ... On 20/12/2013 4:49 PM, David Holmes wrote: On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: Hi David Thanks for your comments, the unguarded part(clean and enqueue) in the Reference Handler thread does not seem to create any new objects, so it is the application

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-06 Thread David Holmes
Hi Tristan, On 7/01/2014 4:43 PM, Tristan Yan wrote: Hi All Please help to review the code change for JDK-7027502. http://cr.openjdk.java.net/~tyan/JDK-7027502/ Description: This test was failed in JPRT test but recently we test with same binaries run, it doesn't fail any more. The intention

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-07 Thread David Holmes
://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.01/ Comma after 2014 still missing in copyright. You need to read total_turns_taken.get() once and use that value in both the println and the == test, so that you print the value you actually tested. David Regards Tristan On 01/07/2014 03:10 PM, David

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-07 Thread David Holmes
On 7/01/2014 8:36 PM, Tristan Yan wrote: Hi David You're totally right. Sorry I ask you review it again. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/ Looks good now. Thanks, David Thank you very much. Tristan On 01/07/2014 05:18 PM, David Holmes wrote: On 7/01/2014 6:16 PM

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-07 Thread David Holmes
- Would be helpful if David/some one else in the team could explain the latent aspects/probable cause. --- Thanks kalyan On 01/06/2014 04:40 PM, David Holmes wrote: Back from vacation ... On 20/12/2013 4:49 PM, David Holmes wrote: On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-07 Thread David Holmes
On 8/01/2014 4:19 PM, David Holmes wrote: On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: Hi David, TraceExceptions with fastdebug build produced some nice trace http://cr.openjdk.java.net/%7Esrikchan/OOME_exception_trace.log . The native method wait(long) is where the OOME if being thrown

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-08 Thread David Holmes
see the Trace output in run() at the point where wait() returns, so it may well be caught after that - in which case this was not a failing run. I also can't reproduce the problem :( David On 8/01/2014 10:34 PM, Peter Levart wrote: On 01/08/2014 07:30 AM, David Holmes wrote: On 8/01/2014 4:19

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-09 Thread David Holmes
On 9/01/2014 8:28 PM, Paul Sandoz wrote: On Jan 9, 2014, at 10:52 AM, Tristan Yan tristan@oracle.com wrote: Can someone else give a second review on this. In a comment the bug you state: here total_turns_taken is a static variable, it could affect by other tests I don't quite know

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-09 Thread David Holmes
On 9/01/2014 9:07 PM, Tristan Yan wrote: Thank you Paul I change turn to local variable as well. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.03/ Okay I think I get it now. Both MonitorTest and WaitersTest use the Context

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-09 Thread David Holmes
On 9/01/2014 9:27 PM, David Holmes wrote: On 9/01/2014 9:07 PM, Tristan Yan wrote: Thank you Paul I change turn to local variable as well. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.03/ Okay I think I get it now. Both

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-09 Thread David Holmes
On 9/01/2014 10:14 PM, Alan Bateman wrote: On 09/01/2014 11:27, David Holmes wrote: Okay I think I get it now. Both MonitorTest and WaitersTest use the Context class, so if both tests run in the same VM the second test will see the static total_turns_taken and turn in the state they were left

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-10 Thread David Holmes
On 10/01/2014 6:40 PM, Staffan Larsen wrote: On 10 jan 2014, at 09:34, Alan Bateman alan.bate...@oracle.com wrote: On 09/01/2014 23:20, Tristan Yan wrote: Hi David I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-13 Thread David Holmes
move for this is move out it from ProblemList and trace down the issue in our normal nightly. Thank you Tristan On 01/10/2014 06:35 AM, David Holmes wrote: On 9/01/2014 10:14 PM, Alan Bateman wrote: On 09/01/2014 11:27, David Holmes wrote: Okay I think I get it now. Both MonitorTest

Re: RFR: (8030875) Macros for checking and returning on exceptions

2014-01-13 Thread David Holmes
Hi Roger, On 11/01/2014 1:37 AM, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev:

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread David Holmes
Just a note on this part (I havent looked at the code): On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread David Holmes
On 15/01/2014 12:10 AM, Volker Simonis wrote: On Tue, Jan 14, 2014 at 12:29 PM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote: Just a note on this part (I havent looked at the code): On AIX, the constants used for the polling events (i.e. POLLIN

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-15 Thread David Holmes
On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: Hi Peter/David, we could finally get a trace of exception with fastdebug build and ReferenceHandler modified (with runImpl() added and called from run()). The logs, disassembled code is available in JIRA

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-16 Thread David Holmes
, David Holmes wrote: On 17/01/2014 4:48 AM, srikalyan wrote: Hi David On 1/15/14, 9:04 PM, David Holmes wrote: On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: Hi Peter/David, we could finally get a trace of exception with fastdebug build and ReferenceHandler modified (with runImpl() added

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-19 Thread David Holmes
Hi Peter, On 17/01/2014 11:24 PM, Peter Levart wrote: On 01/17/2014 02:13 PM, Peter Levart wrote: // Fast path for cleaners boolean isCleaner = false; try { isCleaner = r instanceof Cleaner; } catch (OutofMemoryError oome) { continue; } if (isCleaner) { ((Cleaner)r).clean(); continue;

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread David Holmes
On 21/01/2014 4:54 PM, Peter Levart wrote: On 01/21/2014 03:22 AM, David Holmes wrote: Hi Peter, I do not see Cleaner being loaded prior to the main class on either Windows or Linux. Which platform are you on? Did you see it loaded before the main class or as part of executing it? Before

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread David Holmes
On 22/01/2014 1:24 AM, Peter Levart wrote: On 01/21/2014 07:54 AM, Peter Levart wrote: *[Loaded sun.misc.Cleaner from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* [Loaded java.io.ByteArrayInputStream from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread David Holmes
On 22/01/2014 8:31 AM, Peter Levart wrote: On 01/21/2014 07:17 PM, srikalyan wrote: Hi Peter/David, catching up after long weekend. Why would there be an OOME in object heap due to class loading in perm gen space ? The perm gen is not a problem her (JDK 8 does not have it and we see OOME on

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread David Holmes
it otherwise would? Thanks, David all 10 java/lang/ref tests pass on my PC (including OOMEInReferenceHandler). I kindly ask Kalyan to try to re-run the OOMEInReferenceHandler test with this code and report any failure. Thanks, Peter On 01/21/2014 08:57 AM, David Holmes wrote: On 21/01/2014 4:54 PM

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-23 Thread David Holmes
On 24/01/2014 6:10 AM, srikalyan wrote: Hi Peter, i have modified your code from r = pending; if (r != null) { .. TO if (pending != null) { r = pending; This is because the r is used later in the code and must not be assigned pending unless it is not null(this was as is

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-23 Thread David Holmes
On 24/01/2014 11:53 AM, srikalyan chandrashekar wrote: Hi David, yes thats right, only benefit i see is we can avoid assignment to 'r' if pending is null. I'm okay with either version. David -- Thanks kalyan On 1/23/14 4:33 PM, David Holmes wrote: On 24/01/2014 6:10 AM, srikalyan wrote

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-27 Thread David Holmes
where 'r' is not assigned is not possible because of definitive assignment rules). So I support going back to your version... Regards, Peter -- Thanks kalyan On 1/23/14 4:33 PM, David Holmes wrote: On 24/01/2014 6:10 AM, srikalyan wrote: Hi Peter, i have modified your code from r = pending

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-29 Thread David Holmes
Hi Stuart, This looks fine to me. Tristan: the initialized field is only accessed under synchronization so does not need to be volatile. Cheers, David On 29/01/2014 4:51 PM, Stuart Marks wrote: Hi all, Please review this fix to a race condition in rmid initialization. Briefly, rmid

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-29 Thread David Holmes
This simpler form, with the interruption logic corrected, seems fine to me. David On 30/01/2014 12:57 PM, Stuart Marks wrote: Hi all, wow, lots of comments on this. Let me see if I can tackle them in one message. Quick aside before I get to the issues: my priorities for this code are

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-30 Thread David Holmes
of interrupt handling is you either throw InterruptedException or you re-assert the interrupted state. This allows code further up the stack to respond to interrupts. David Thank you Tristan On Jan 30, 2014, at 11:24 AM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote

Re: Which optimizations does Hotspot apply?

2014-01-30 Thread David Holmes
Hotspot questions belong on hotspot lists. cc'ing hotspot-dev and (trying to) bcc core-libs-dev. David On 23/01/2014 9:37 AM, Remi Forax wrote: On 01/22/2014 11:37 PM, Robert Stupp wrote: Is there any documentation available which optimizations Hotspot can perform and what collecting a

Re: RFR [9] 8031050: [macosx] Crash while awt starting

2014-02-03 Thread David Holmes
On 3/02/2014 11:54 PM, Alan Bateman wrote: On 03/02/2014 13:18, Chris Hegarty wrote: Hi, An old issue has resurfaced because of a change in AWT. AWT, now, on Mac OS X, attaches a system graphics thread to the running VM, using JNI_AttachCurrentThread. This change can result in a NPE, if a

Re: RFR: 8033565: Remove unused nativeNewStringPlatform and nativeGetStringPlatformChars

2014-02-05 Thread David Holmes
On 6/02/2014 8:58 AM, roger riggs wrote: Please review this change to remove unused support in jni_util.c for functions nativeNewStringPlatform and nativeGetStringPlatformChars. On Windows, both were conditional on jvm.dll being installed on a path containing kernel. On Solaris, Linux, and Mac,

Re: RFR: JDK-8034906 Fix typos, errors and Javadoc differences in java.time

2014-02-19 Thread David Holmes
Hi Stephen, This could be construed as a spec-change, even if a typo :( - * which are too large to fit in an {@code int} and throw a {@code DateTimeException}. + * which are too large to fit in an {@code int} and throw an {@code UnsupportedTemporalTypeException}. David On 19/02/2014 8:54

Re: RFR: JDK-8034906 Fix typos, errors and Javadoc differences in java.time

2014-02-19 Thread David Holmes
to the case that this was a simple typo. But once this has shipped (and JDK 8 is untying from the dock) the distinction may be moot - we have a spec and code that disagree so one must be changed. David Stephen On 19 February 2014 11:08, David Holmes david.hol...@oracle.com wrote: Hi Stephen

Re: RFR: JDK-8034906 Fix typos, errors and Javadoc differences in java.time

2014-02-19 Thread David Holmes
On 19/02/2014 10:04 PM, Stephen Colebourne wrote: On 19 February 2014 11:39, Alan Bateman alan.bate...@oracle.com wrote: On 19/02/2014 11:08, David Holmes wrote: Hi Stephen, This could be construed as a spec-change, even if a typo :( - * which are too large to fit in an {@code int

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
Hi Brian, On 20/02/2014 7:44 AM, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue: https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev: http://cr.openjdk.java.net/~bpb/8035279/webrev.00/ All JTREG BigInteger tests pass, and the serialized

Re: Discussion on root cause analysis of JDK-7052625 : com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently

2014-02-20 Thread David Holmes
Sounds like a question for net-dev more than core-libs - cc'd. David On 20/02/2014 4:11 PM, michael cui wrote: On 02/18/2014 12:51 AM, michael cui wrote: Hi, I would like to discuss my current root cause analysis of JDK-7052625 : com/sun/net/httpserver/bugs/6725892/Test.java fails

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
false in hotspot (except for the new AIX/PPC64 port). Thanks, David On 21/02/2014 3:55 AM, Peter Levart wrote: On 02/20/2014 11:20 AM, David Holmes wrote: Hi Brian, On 20/02/2014 7:44 AM, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue: https

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
On 21/02/2014 7:20 AM, Paul Sandoz wrote: On Feb 20, 2014, at 9:09 PM, David Holmes david.hol...@oracle.com wrote: In practice, because there are also final fields in these instances implementations will most likely perform a storestore barrier after construction and prior to setting

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
On 21/02/2014 9:52 AM, Doug Lea wrote: On 02/20/2014 05:11 PM, David Holmes wrote: On 21/02/2014 7:20 AM, Paul Sandoz wrote: On Feb 20, 2014, at 9:09 PM, David Holmes david.hol...@oracle.com wrote: In practice, because there are also final fields in these instances implementations will most

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
On 21/02/2014 10:28 AM, John Rose wrote: On Feb 20, 2014, at 12:09 PM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote: If the sentinel values were the default zero values there would be no issue This is an instance of the stable value pattern; see the javadoc

Re: Type of Class

2014-02-21 Thread David Holmes
On 21/02/2014 3:38 AM, Stephen Colebourne wrote: In JDK 5, three methods were added to java.lang.Class [1] - isAnonymousClass() - isLocalClass() - isMemberClass() Unfortunately, these do not cover the complete range of possible types of class. I think they do once you realize that the static

Re: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently

2014-02-23 Thread David Holmes
Hi Tristan, I don't have time to analyse the original failure mode nor your proposed changes but ... On 23/02/2014 7:40 PM, Tristan Yan wrote: Hi All Could you please help to review fix for JDK-803174. http://cr.openjdk.java.net/~tyan/JDK-8031374/webrev.00/ Description: There are a couple

Re: RFR [6853696] (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired

2014-02-24 Thread David Holmes
On 25/02/2014 1:34 AM, Ivan Gerasimov wrote: Thank you Roger for looking at the fix! On 24.02.2014 18:37, roger riggs wrote: Hi Ivan, The code is correct as written but there might be some creep in the end time due to the sampling of System.nanoTime. I would be inclined to calculate the

Re: RFR [6853696] (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired

2014-02-24 Thread David Holmes
On 25/02/2014 1:49 PM, Ivan Gerasimov wrote: On 25.02.2014 6:52, David Holmes wrote: On 25/02/2014 1:34 AM, Ivan Gerasimov wrote: Thank you Roger for looking at the fix! On 24.02.2014 18:37, roger riggs wrote: Hi Ivan, The code is correct as written but there might be some creep in the end

Re: RFR [6853696] (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired

2014-02-25 Thread David Holmes
Hi Ivan, 143 long start = (timeout == 0) ? 0 : System.nanoTime(); This can simply be: 143 long start = System.nanoTime(); If timeout==0 then you will never execute the code that even looks at start. Cheers, David On 26/02/2014 7:46 AM, Ivan Gerasimov wrote: Thank

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-26 Thread David Holmes
On 27/02/2014 5:30 PM, Peter Levart wrote: On 02/27/2014 08:29 AM, Peter Levart wrote: On 02/26/2014 09:54 PM, Martin Buchholz wrote: I don't recall having added this particular wart to test/java/lang/ProcessBuilder/Basic.java, and history suggests that others did that. It does seem that

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread David Holmes
On 27/02/2014 6:38 PM, Peter Levart wrote: On 02/27/2014 08:41 AM, David Holmes wrote: On 27/02/2014 5:30 PM, Peter Levart wrote: On 02/27/2014 08:29 AM, Peter Levart wrote: On 02/26/2014 09:54 PM, Martin Buchholz wrote: I don't recall having added this particular wart to test/java/lang

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-27 Thread David Holmes
On 26/02/2014 10:56 PM, Peter Levart wrote: On 02/25/2014 09:38 PM, Brian Burkhalter wrote: On Feb 20, 2014, at 1:42 AM, Paul Sandoz wrote: Not sure the static powerCache field, in the original code, needs to be volatile either: 1137 private static volatile BigInteger[][] powerCache; Is

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread David Holmes
On 27/02/2014 9:12 PM, Stephen Colebourne wrote: On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote: It does seem that being able to tell whether a java object monitor is currently locked is useful for debugging and monitoring - there should be a way to do that. Perhaps it

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

2014-02-28 Thread David Holmes
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 strip the symbols from the binary. The former is trivial. The latter is more awkward as the strip policy stuff does not work as I would want it to work, but

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

2014-02-28 Thread David Holmes
Thanks, Yasumasa On 2014/02/28 23:04, Daniel D. Daugherty wrote: 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

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

2014-03-02 Thread David Holmes
. Thanks, David Thanks, Yasumasa On 2014/03/01 8:47, David Holmes wrote: On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: The proper way to fix this is to disable FDS. Does this mean I have to pass --disable-debug-symbols to configure ? I've added comment to JDK-8036003, I think if we pass

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-03-03 Thread David Holmes
Frijters jer...@sumatra.nl wrote: David Holmes wrote: I don't think this is workable. Exposing a monitor as Lock would allow you to break the guarantees/requirements involving balanced-locking for monitors. Where are these guarantees/requirements documented? Regards, Jeroen

  1   2   3   4   5   6   7   8   9   10   >