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

Thanks Peter. Kalyan: Can you confirm, as Peter asked, that the TraceExceptions output came from a failed run? AFAICS the Trace info is printed after each bytecode where there is a pending exception - though I'm not 100% sure on the printing within the VM runtime. Based on that I think we se

Re: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers

> On 8 Jan 2014, at 20:04, Mandy Chung wrote: > > >> On 1/8/2014 11:30 AM, Daniel Fuchs wrote: >> >> > > The fix looks fine. The WeakReference and System.gc() call was to help > reproduce the test failure. I wonder if it'

Re: JDK 9 proposal: remove sun.misc.Ref

On 1/8/2014 1:06 AM, Alan Bateman wrote: On 07/01/2014 22:26, Joe Darcy wrote: So the type has been deprecated for at least 10 years. Rather than fixing the warning in the class, I think the best course of action is to remove the file in JDK 9. A build of OpenJDK without this file builds fi

JMM9 Project (Java Memory Model revisions for JDK9)

[to hotspot-dev, cross-post to core-libs-dev] We are proposing the creation of the JMM9 Project with Doug Lea as the Lead and Hotspot as the sponsoring Group. JMM9 is unusual as a Project in that it will not produce software, so there is no suggested initial list of Authors. The sponsoring Group

Re: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers

On 1/8/2014 11:30 AM, Daniel Fuchs wrote: The fix looks fine. The WeakReference and System.gc() call was to help reproduce the test failure. I wonder if it's really needed to be retained in the test (or better to remove

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

Hi Peter, the jtreg test configuration is @run main/othervm -Xmx24M -XX:-UseTLAB OOMEInReferenceHandler. With this option you still have to run the test several times(like a 1000 runs) to capture 1(OR) more failures. Platform may not have an affect, however i used a 64 bit Ubuntu 12.04 LTS , 8

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

Kal, Can you give access to Peter to the machine where you ran this test. Please send the details to him privately. Thanks, Sandeep On Jan 8, 2014, at 12:08 PM, srikalyan chandrashekar wrote: > Hi Peter, the jtreg test configuration is @run main/othervm -Xmx24M > -XX:-UseTLAB OOMEInReferenc

Re: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers

On 1/8/14 6:48 PM, Chris Hegarty wrote: The cleanup looks fine to me, and the retaining of strong refs to the loggers. Is the weak ref guaranteed to be cleared at some point? Hi Chris, I added a counter to the loop just to make sure it won't loop infinitely. Note that the goal of the loop is

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

On 08/01/2014 18:48, Dan Xu wrote: Hi Alan, Btw, I am wondering whether I need pass a variable to see if the returned char* is a copy or not, and basing on that to do the release. For example, jboolean isCopy; const char *fname = JNU_GetStringPlatformChars(env, java_fname, &isCopy); if (isCo

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

Hi Alan, Btw, I am wondering whether I need pass a variable to see if the returned char* is a copy or not, and basing on that to do the release. For example, jboolean isCopy; const char *fname = JNU_GetStringPlatformChars(env, java_fname, &isCopy); if (isCopy == JNI_TRUE) JNU_ReleaseStri

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

Thank you, Alan. I will add this change into my fix and push it today. Thanks! -Dan On 01/08/2014 01:24 AM, Alan Bateman wrote: On 08/01/2014 00:50, Dan Xu wrote: Hi All, Thanks for your good review. I have dropped the change in FileSystemPreferences.java , and created the new webrev which

Re: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers

On 1/8/14 6:48 PM, Chris Hegarty wrote: The cleanup looks fine to me, and the retaining of strong refs to the loggers. Is the weak ref guaranteed to be cleared at some point? Hopefully yes - my experiments show that it's cleared at the first iteration. Do you think I should add a counter - or

Re: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers

The cleanup looks fine to me, and the retaining of strong refs to the loggers. Is the weak ref guaranteed to be cleared at some point? -Chris > On 8 Jan 2014, at 17:34, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for a test bug: > 8031068: java/util/logging/ParentLoggersTest.jav

JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers

Hi, Please find below a patch for a test bug: 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers https://bugs.openjdk.java.net/browse/JDK-8031068 As usual -

hg: jdk8/tl/jdk: 3 new changesets

Changeset: 5d05be02629c Author:mfang Date: 2014-01-07 21:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d05be02629c 8029239: jdk8 l10n resource file translation update - localenames Reviewed-by: okutsu ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties !

hg: jdk8/tl/jdk: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 2437ccbf3504 Author:erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java

hg: jdk8/tl: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 53d74b77ee53 Author:erikj Date: 2014-01-08 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/53d74b77ee53 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb, ihse, tbell ! common/autoconf/generated-configure.sh ! c

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

Hi Kalyan, What hardware/OS/JVM and what JVM options are you using to reproduce this failure. I would really like to reproduce this myself, but all attempts on my PC have so far been unsuccessful. I might be able to get access to a machine that is similar to yours... Regards, Peter On 01/07

Re: (reflect) Accessing members of inner annotations types

On 2014-01-08, Peter Levart wrote: > On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: > >> > >Perhaps an alternative would be to check if the interface a proxy is > >proxying is nested. In that case use the outermost interface's access > >level for the package calculation. > > > >This would prob

Re: (reflect) Accessing members of inner annotations types

On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: Hi Peter, On 2014-01-03, Peter Levart wrote: On 01/03/2014 03:52 PM, Peter Levart wrote: This is would be all right until such proxy class (com.sun.proxy.$Proxy1 in our example) has to access some package-private types in some specific packag

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

On 08/01/2014 12:57, Tristan Yan wrote: Thank you. This is a very detailed explanation. I had new webrev with removing othervm. Thanks, looks good. I've pushed it to jdk9/dev/jdk for you. -Alan

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Thank you. This is a very detailed explanation. I had new webrev with removing othervm. http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.01/ Regards Tristan On 01/08/2014 08:51 PM, Alan Bateman wrote: On 08/01/2014 11:01, Tristan Yan wrote: Hi Alan Maybe my understanding is wrong. Are you s

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

On 08/01/2014 11:01, Tristan Yan wrote: Hi Alan Maybe my understanding is wrong. Are you saying even in agentvm mode, there will be still different VM for every test. If the answer is yes, when should we use othervm mode? The purpose of -agentvm is to speed up the test execution by eliding the

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

On 01/08/2014 07:30 AM, David Holmes wrote: 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 . The native metho

Re: (reflect) Accessing members of inner annotations types

Hi Peter, On 2014-01-03, Peter Levart wrote: > On 01/03/2014 03:52 PM, Peter Levart wrote: > >This is would be all right until such proxy class > >(com.sun.proxy.$Proxy1 in our example) has to access some > >package-private types in some specific package. This happens in > >your Named.List annotat

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Hi Alan Maybe my understanding is wrong. Are you saying even in agentvm mode, there will be still different VM for every test. If the answer is yes, when should we use othervm mode? Thank you Tristan On 01/08/2014 06:45 PM, Alan Bateman wrote: On 08/01/2014 10:09, Tristan Yan wrote: Thank yo

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

On 08/01/2014 10:09, Tristan Yan wrote: Thank you Alan. I am appreciated that you sponsor this. The reason I changed it to othervm is I don't want System.gc do any impact to other tests, assume in concurrent mode. With concurrency then an agent VM still only runs one test at a time, it's just t

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Thank you Alan. I am appreciated that you sponsor this. The reason I changed it to othervm is I don't want System.gc do any impact to other tests, assume in concurrent mode. Regards Tristan On 01/08/2014 05:58 PM, Alan Bateman wrote: On 08/01/2014 02:38, Tristan Yan wrote: Hi All Please help

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

On 08/01/2014 02:38, Tristan Yan wrote: Hi All Please help to review code fix for bug JDK-8030089. http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.00/ Description: 1. Set test running on othervm mode. 2. Use infinite wait to the

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

On 08/01/2014 00:50, Dan Xu wrote: Hi All, Thanks for your good review. I have dropped the change in FileSystemPreferences.java , and created the new webrev which only changes FileSystemPreferences.c. Please help review it. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev.01/

Re: JDK 9 proposal: remove sun.misc.Ref

On 07/01/2014 22:26, Joe Darcy wrote: So the type has been deprecated for at least 10 years. Rather than fixing the warning in the class, I think the best course of action is to remove the file in JDK 9. A build of OpenJDK without this file builds fine; if a build of the closed sources goes f

Re: JDK 9 proposal: remove sun.misc.Ref

On 01/08/2014 03:26 AM, Stuart Marks wrote: On 1/7/14 2:26 PM, Joe Darcy wrote: public abstract class Ref { So the type has been deprecated for at least 10 years. Rather than fixing the warning in the class, I think the best course of action is to remove the file in JDK 9. A build of OpenJDK