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

2014-01-08 Thread Remi Forax
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

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

2014-01-08 Thread Alan Bateman
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

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

2014-01-08 Thread Tristan Yan
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

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

2014-01-08 Thread Alan Bateman
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

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

2014-01-08 Thread Tristan Yan
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

Re: (reflect) Accessing members of inner annotations types

2014-01-08 Thread Joel Borggren-Franck
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 annotation

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

2014-01-08 Thread Peter Levart
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 http://cr.openjdk.java.net/%7Esrikchan/OOME_exception_trace.log . The native method

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

2014-01-08 Thread Alan Bateman
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: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

2014-01-08 Thread Tristan Yan
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

Re: (reflect) Accessing members of inner annotations types

2014-01-08 Thread Peter Levart
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

Re: (reflect) Accessing members of inner annotations types

2014-01-08 Thread Joel Borggren-Franck
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 probably lead to

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

2014-01-08 Thread erik . joelsson
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 !

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

2014-01-08 Thread erik . joelsson
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/jdk: 3 new changesets

2014-01-08 Thread michael . fang
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

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

2014-01-08 Thread Daniel Fuchs
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 -

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

2014-01-08 Thread Dan Xu
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

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

2014-01-08 Thread Dan Xu
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)

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

2014-01-08 Thread Alan Bateman
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

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

2014-01-08 Thread Daniel Fuchs
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: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-08 Thread Sandeep Konchady
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 srikalyan.chandrashe...@oracle.com wrote: Hi Peter, the jtreg test configuration is @run main/othervm

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

2014-01-08 Thread Mandy Chung
On 1/8/2014 11:30 AM, Daniel Fuchs wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.01/ 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

JMM9 Project (Java Memory Model revisions for JDK9)

2014-01-08 Thread Doug Lea
[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

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

2014-01-08 Thread Mandy Chung
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

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

2014-01-08 Thread Chris Hegarty
On 8 Jan 2014, at 20:04, Mandy Chung mandy.ch...@oracle.com wrote: On 1/8/2014 11:30 AM, Daniel Fuchs wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.01/ The fix looks fine. The WeakReference and System.gc() call was to help reproduce the test failure. I

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

2014-01-08 Thread David Holmes
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